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
- Introduce new definitions in descriptors.proto
- Add new corresponding values in Flags.java
- Introduce ContractSerializer and ContractDeserializer, responsible for
for conversion ContractDescription <-> ProtoBuf.Contract
- Add dependency of 'serialization' module on 'resolution' so that it
could see contracts model.
Note that here we do a lot of seemingly unnecessary hoops, which in fact
necessary to respect existing module system (in particular, to be able
to extract ContractDescription declarations from 'descriptors' module to
make them invisible from reflection)
==========
Effect System introduction: 8/18
- Introduce DSL for declaration of contracts. Functions and classes in
this DSL do not bear any computational semantics: in fact, they all do
not exist on runtime. Whole work of extracting semantics from such calls
is done by special parts of compiler
- To make distinguishing those declarations more robust and
convenient, introduce internal annotation @ContractsDSL
- Turn off InlineChecker inside contracts DSL. We do this, because some
functions from DSL should take any possible lambda, so we can't write
any type besides 'Function<R>'. However, InlineChecker will complain if
we will pass inlined lambda in such function -- though, this is false
positive because we know that functions from contracts DSL will never be
executed
- Change testData on HierarchyTestWithLib, where new enum from
kotlin.internal changed expected output
==========
Effect System introduction: 7/18
- Add facade of effect system in form of EffectSystem class, as well as
some other utility classes.
- Inject effect system facade classes into ExpressionTypingComponents
- Call to ContractParsingServices in ExpressionTypingVisitor to record
function contract (if any)
- Introduce FilteringTrace
- Create new FilteringTrace for statement in ExpressionTypingServices
that will serve as a cache for EffectSystem, filtering ES-related
slices from committing into parent.
- Extract and expose ConditionalDataFlowInfo
==========
Effect System introduction: 6/18
- Introduce part of effect system responsible for parsing
contracts which were expressed in sources using DSL from stdlib
- Add new errors to Errors.java related to contracts and corresponding
messages.
==========
Effect System introduction: 5/18
Add model of contracts used by compiler during analysis. It should be
thought of as structure which used by the compiler to implement
semantics, expressed by the ContractDescription.
==========
Effect System introduction: 2/18
Add ContractDescription structure which is used for declarative representation
of function's contract.
Also, add corresponding LanguageFeatures.
==========
This is the first commit from a series of 18 commits which gradually
introduce effect system into the compiler. All such commits will be
marked with appropriate comment and index in that series.
While each one of such commits separately shouldn't break compiler (i.e
you can checkout any of them and expect compiler to build and pass
tests successfully, e.g. for bissecting purposes), semantically they
all are one big feature and not entirely independent. Please bear that
in mind while working with/changing only some of them -- some strange
effects can happen.
There are a lot of places requesting nothing/any/.. instances
and just asking the scopes isn't very effecient:
see org.jetbrains.kotlin.builtins.KotlinBuiltIns#createPackage
having ChainedMemberScope and a `map` call
Dmitry Savvinov