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
Jinseong Jeon