Codegen generates static backing fields for object properties.
They are initialized in class constructor but some of them are final static
and such access is prohibited in specification but it's allowed in
java bytecode <= 1.8. Such access in 1.9 bytecode cause
"IllegalAccessError: Update to static final field Object.INSTANCE
attempted from a different method (<init>) than the initializer method <clinit>"
Added additional hidden field in interface companion to pass out
companion instance from <clinit>.
#KT-15894 Fixed
This flag is used internally by EffectSystem as a sign of compiling
stdlib. If this flag is present, then EffectSystem will read contracts
on functions and serialize them into metadata even if corresponding
LanguageFeatures are turned off. This is done solely for building
1.2-runtime with contracts in it without the need to turn on
LanguageFeatures manually.
======
This commit finishes a first series of commits related to effect
system. After it, compiler is ready to work with contracts, but it is
impossible to actually annotate anything, because there are no
contracts DSL in stdlib yet.
Support initialization of local variables in capture, if that capture is
anonymous lambda that was passed to function which explicitly expressed
its intent to call closure "here and now"
Changes:
- LocalFunctionDeclarationInstruction made open
- Introduce InlinedLocalFunctionDeclarationInstruction, which is subtype
of LocalFunctionDeclarationInstruction with additional semantic: it
is statically known that this function will be called in-place and maybe
with some definite amount of invocations.
- Next-instruction of InlinedLocalFunctionDeclarationInstruction depends
on whether flow can exit its body normally, i.e. on wheter EXIT is
reachable. If flow can reach EXIT, then .next is just straight next
instruction, otherwise it's SINK.
- Take non-local instructions into consideration when analyzing
reachability. We didn't it before because no one ever needed proper
analysis. Now we have InlinedLocalFunctionDeclarationInstruction which
cares about proper reachability of EXIT.
- Pull control-flow information from
InlinedLocalFunctionDeclarationInstruction's EXIT into parent's
pseudocode, thus allowing it to participate in initialization/use
analysis.
- Change logic of 'isCapturedWrite' to not report
"CAPTURED_VAL_INITIALIZATION" if value is captured by the inline-lambda.
==========
Introduction of EffectSystem: 12/18
- Support functions that explicitly express relation between successfull
return and passed arguments (e.g., 'check')
- Note that we have to correct resulting data flow for arguments *after*
resoling (because we get contracts only after resolving). To do so, we
have to extend MutableDataFlowInfoForArguments interface with
'updateResultInfo' method.
==========
Introduction of EffectSystem: 11/18
Support functions which have explicitly expressed relation between
return-value and arguments. If we have observed that function returned
this value, get additional information from effect system.
==========
Effect System introduction: 10/18
Make a fastcheck for a presence of contract-declaration in function
body of FunctionDescriptorResolver. If there's something that looks like
contract and we need resolve to make a final decision, then prepare
LazyContractProvider key in UserDataMap of function's descriptor.
Note that we can't passively wait with contracts resolving until the
function body is analyzed, because we may need it earlier. However, we
can't force body resolve straight during descriptors resolving, because
we can run into recursive problems. That's why we are saving deferred
resolving of functions body via LazyContractProvider.
Also, we have to pass DataFlowInfo into
initializeFunctionDescriptorAndExplicitReturnType, because we save
deferred body resolving inside, which needs DataFlowInfo.
==========
Effect System introduction: 9/18
Ilya Gorbunov