- An `OptionalAnnotationClassesProvider` only needs to be created if the
package part provider may even have optional annotation classes.
- In the IDE case, the package part provider never provides optional
annotation classes, so especially in the IDE, we can avoid a lot of
useless symbol providers with this.
This fixes an issue where an actual class from an intermediate module
has more supertypes than its expect declaration which leads to a
false-positive resolution error because a type reference resolves to the
expect class. The fix is to sort the dependencies topologically from
"most actual" to "most expect" when creating the list of symbol
providers.
#KT-57369 Fixed
It's a common compiler argument and may be applied to any compile task, there's no reason to set it separately for K/JS and K/JVM, and now it sets the compiler argument for metadata compilation tasks as well
The problem was that we were using unenhanced constructors that still
might contain java type refs.
Basically, most of the `firClass.declarations` usages are unsafe in that
meaning.
The test is very complicated because to reproduce the exception there
should be some conditions met:
- MyClass should be compiled with K1, so it has `@EnhancedNullability`
annotation serialized (that is unnecessary, but don't do any harm)
- `@Nls` scope should be properly resolved, so enum entries are converted
to resolved type refs
- That leads to attempt to check if null-check might be needed to be
inserted and to failure at FirTypeUtilsKt.getCanBeNull
While this quite controversial to have this check being performed for
freshly created annotations calls, the problem with improper constructor
lookup anyway existed and fixed correctly.
^KT-57213 Fixed
In a lot of cases, when we want to process the
declaration in scope, it should be resolved to at least TYPES phase.
To avoid doing it manually in all our variety of scopes, we do it when the scope it created.
It was implicitly working manually before as lazy resolve did a lot of extra work
on resolving a declaration it was not supposed to resolve.
Now it's not the case, and we have to explicitly resolve all the declarations we need.
^KT-56543
Co-authored-by: Ilya Kirillov <ilya.kirillov@jetbrains.com>
Dmitriy Novozhilov