This behavior was used until 6a1b6d10d8, where the JDK has
unintentionally started to be added to the end of the list, breaking
code which depended on libraries which bundle something from the JDK
#KT-21299 Fixed
Currently there are two major phases in NI that report diagnostics: resolution parts and completion. They connected in method `KotlinCallCompleter.runCompletion` and previously diagnostics were collected in several places, from resolution atoms, partly from constraint system and partly from `CallResolutionResult`, some of them were lost.
To mitigate this problem, now diagnostics are not bind to the intermediate candidate, only to the result resolution candidate (overloaded or usual one). And all diagnostics are now collected in method `runCompletion`
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.
Alexander Udalov