Single execution path to report missing package fragment problems
Split failures on PluginDeclarationProviderFactory site by
known reasons to improve exception analysis
When recursion is detected while computing
`ClassResolutionScopesSupport.scopeForMemberDeclarationResolution`,
create 'ThrowingLexicalScope' (as with other scopes), instead of
throwing ISE immediately. That allows to report error properly in cases
like in KT-18514
#KT-18514 Fixed
It's necessary for performance, because there are some resolution
parts that actually can be omitted and at the same time they aren't
very cheap (like inference or value arguments types checking)
On JVM, strip @EnhancedNullability annotation from inferred types for
functions, properties, and local variables, so that these annotations
do not "escape" from Kotlin declarations.
Note that current behaviour is made similar to the case with
properties initializers/accessors, which means that more complex
cases are not covered yet (see KT-20801) #KT-20802 fixed.
Divide incompatibility on two groups: strong and weak. Strong incompatibility means that if declaration with such incompatibility has no `actual` modifier then it's considered as usual overload and we'll not report any error on it.
#KT-20540 Fixed
#KT-20680 Fixed
This commit support the following case.
Suppose we have such declaration:
fun <T> foo(): T { ... }
Then in code we want to use it like this: `foo() as String`.
But in LV <= 1.1 we have type inference error: "Not enough
information for type parameter `T`". This error happened because we
do not use type from cast as expected type for call.
In this commit we fix this problem and use this type as expected type
in following cases:
- our function has only one type parameter (this can be relaxed later)
- function parameter types and extension receiver type not contains `T`
Also this fix problem with `findViewById`.
Already signature was: `fun findViewById(...): View`
and was used like: `findViewById() as MyView`.
New signature is `fun <T : View> findViewById(...): T`
and old usage was broken because of problem described above
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
- 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
The simple versions of KotlinTypeFactory::simpleType may lead
to smaller number of KotlinType instances
(defaultType from descriptor are used if there are no arguments)
Because of com.intellij.openapi.vfs.local.CoreLocalVirtualFile#getPath
that has a rather slow implementation calling String::replace on each call
At the same time this method gets called very frequently when
recording lookups
- Do not calculate smart cast variants unless they're not necessary
- Avoid calling subtyping twice just to know if smart cast is necessary
(now the needed info is contained in ReceiverSmartCastResult)
Nikolay Krasko