Such as:
- PackageFragmentProviders, and, in particular,
CompositePackageFragmentProviders
- JavaPackageFragments
- Scopes produced by those providers
The rationale is that a lot of frontend-facing bugs (like red code) are
easily recognizeable in resolution. But at that point you just see a
bunch of scopes, without meaningful toStrings, you don't know who has
produced them, and what's exactly wrong.
With this commit it should make debugging slightly easier: now at least
you'll be able to see that "this scope is a scope of package fragment
for foo.bar of module baz" and decide whether the declaration should or
should not have been resolved from such scope.
It fixes:
```
java.lang.NoClassDefFoundError: org/jetbrains/kotlin/fir/FirCfgConsistencyChecker
at org.jetbrains.kotlin.test.frontend.fir.handlers.FirCfgConsistencyHandler.processModule(FirCfgConsistencyHandler.kt:15)
at org.jetbrains.kotlin.test.frontend.fir.handlers.FirCfgConsistencyHandler.processModule(FirCfgConsistencyHandler.kt:13)
at org.jetbrains.kotlin.test.TestRunnerKt.processModule(TestRunner.kt:236)
at org.jetbrains.kotlin.test.TestRunnerKt.hackyProcess(TestRunner.kt:231)
at org.jetbrains.kotlin.test.TestRunnerKt.access$hackyProcess(TestRunner.kt:1)
```
while running `DiagnosisCompilerTestFE10TestdataTestGenerated.Tests#testBinaryCallsOnNullableValues` (and probably other tests) in new infrastructure
We need to have IdeTestIgnoreHandler executed after FirFailingTestSuppressor,
otherwise IdeTestIgnoreHandler will suppress exceptions
and FirFailingTestSuppressor will throw error
saying that file .fir.fail exists but test passes
This avoids an extra call to 'analyze', which is rather costly.
Update debugger testData: Constant condition
elimination now performs DCE more consistently.
This filters it out for use in SAM wrapper generation with
invoke-dynamic.
The intrinsic is not actually used for code generation so
it is added to the list of intrinsics that should have been
lowered away before codegen.
^KT-45779 Fixed
Use ClassLoader.getResource + openStream instead, to workaround an issue
in URLClassLoader.
Also set useCaches to false because kotlin-reflect only reads builtins
metadata once per class loader, and doesn't need it to be cached. Using
caches here might also lead to the problem of closed input streams when
protobuf is read in parallel. The test doesn't check exactly this,
though (it seems to succeed even if cached connections are used).
Note that BuiltInsResourceLoader has a JDK 9+ specialization at
libraries/reflect/api/src/java9, but that implementation does not need
any changes because it uses Module.getResourceAsStream which is not
affected by this issue in URLClassLoader.
#KT-18277 Fixed
As part of this change, we also extend the usage of RealVariable in more
places during DFA. Now mutable properties, property with custom getters,
delegated properties, etc are also treatd as a `RealVariable`. In
general this is needed in order to carry out smartcast computation in
order to report `SMARTCAST_IMPOSSIBLE`. It seems to also have side
effects that improves behavior of some test files.
Looks like it was added accidentally in 564d382b9d; common frontend
shouldn't depend on JVM-specific modules.
Since then, it has been accidentally used in two places in
ir.serialization.common to refer to JVM specifics, and that should be
abstracted away in the future.
To avoid depending on a heavy module 'frontend' in parts of the compiler
where checking for optional annotations is needed, such as in
'ir.serialization.common'.
Dmitry Savvinov