The problem is that when performing full analysis we do it in
a backward order while result for trivial vals is filled
in a forward one.
It turns out that reversedInstuctions might return a superset of
forward traversed instructions, e.g. in case of dead code in lambda.
At the same time result for trivial vals is constant
for any instruction, thus we can just return its constant value
and use it in the full analysis
#KT-20895 Fixed
Make ScriptDefinitionProvider an interface
and provide different implementation for cli and IDEA
Rework ide extension point to a simpler interface (ScriptDefinitionContributor)
Move template loading logic into a top level function
Allow script definitions to be reloaded in IDE
Also use more safe way to report errors: only if there is corresponding PSI element. This is not very useful for compiler, but in IDE we can get synthetic calls with null psi arguments
In NI type checking actually performs in constraint system. To be conservative, now we still perform full type cheking but only if there is no contradiction in constraint system
Consider the following example:
class A {
operator fun <T> invoke(): Foo<T> = throw Exception()
}
fun foo(f: Foo<Int>) {}
fun test(a: A) {
foo(a()) // after resolve of `invoke`, it has non-fixed type variable
}
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
Mikhail Zarechenskiy