- This optimization applied to LL FIR can be extended to K2 as a whole.
Likely, there won't be any performance benefits in CLI runs, but it's
still better to avoid useless symbol providers.
- Dependency symbol providers contained a lot of useless
`FirExtensionSyntheticFunctionInterfaceProvider`s, because such a
provider only generates function classes from compiler plugins. If
there aren't any such `FunctionTypeKind`s in the session, there is no
need to even add the provider.
- `FirExtensionSyntheticFunctionInterfaceProvider`s that are added to
the list of dependency providers despite this optimization will now be
combined in `LLFirCombinedSyntheticFunctionSymbolProvider`. It checks
`ClassId` heuristics once, which is more efficient than checking them
in every provider separately.
- Similar to the implementation of `isNameForFunctionClass` in
`FirSymbolProvider`, `FirSyntheticFunctionInterfaceProvider` benefits
from checking the `ClassId` for a digit before accessing its class
cache.
- Replace the "recurse one layer deep" approach of
`LLFirDependentModuleProviders` with a flattened list of dependency
symbol providers.
- This refactoring is a necessary component of supporting combined
symbol providers.
Basically, this commit reworks eraseToUpperBound* stuff
Instead of a bunch of vague flags, we introduce two modes
(rawTypes/intersection emptiness checker) which defined those flags.
Also, it makes choosing `eraseArgumentsDeeply` option always because
that how it works in K1 and also use invariant projection inside
`eraseArgumentsDeeply` for raw types for the same reason.
^KT-57198 Fixed
These tests won't be FIR_IDENTICAL after the next commit. That's why I
split them prematurely. This allows me to have a nicer diff in `2/2`
commit.
In scope of KT-15470
Review: https://jetbrains.team/p/kt/reviews/9250
IC: Compute symbols impacted by classpath changes
Incremental compilation has 4 key steps:
1. Compile changed/impacted files
2. Detect symbols that have changed after compiling
3. Detect symbols that are impacted by the changed symbols
4. Based on the changed-or-impacted symbols, identify files that need
to be recompiled. Go back to step 1.
Normally, step 2 and 3 are done together when the changed symbols
and impacted symbols are in the same module.
However, if the changed symbols and impacted symbols are in different
modules (e.g., a `Subclass` in lib1 extends a `Superclass` in lib2),
we currently do not compute symbols in the current module that are
impacted by changes in another module (step 3 above).
This is the case for both the new IC and the old IC.
In this commit, we will compute impacted symbols for the new IC. We can
fix the old IC later if necessary (they can't be fixed together easily).
Test: Added BaseIncrementalCompilationMultiProjectIT.testChangeInterfaceInLib
^KT-56197 Fixed
Sometimes Gradle hangs during relocation of compiler plugins because
`compilerDummyJar` configuration is resolved inside ShadowJar's exclude
https://github.com/gradle/gradle/issues/24317
Ivan Kochurkin