- 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.
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>
- If the callee reference in a desugared compound assignment was an
error reference, the compound assignment wasn't cached by
`FirElementsRecorder`. This led to KTIJ-24895 (see the issue for more
details).
- The solution falls back on the compound assignment's source to decide
`isSourceForCompoundAccess`, as an operation name can be reconstructed
from the PSI.
^KTIJ-24895 fixed
We can't reduce resolve to COMPILER_REQUIRED_ANNOTATIONS phase for
annotations with arguments, because currently they don't have
argument mapping
```stracktrace
org.jetbrains.kotlin.utils.KotlinExceptionWithAttachments: By now the annotations argument mapping should have been resolved
at org.jetbrains.kotlin.analysis.api.fir.annotations.FirAnnotationUtilsKt.mapAnnotationParameters(firAnnotationUtils.kt:137)
at org.jetbrains.kotlin.analysis.api.fir.FirUtilsKt.toKtAnnotationApplication(FirUtils.kt:79)
at org.jetbrains.kotlin.analysis.api.fir.annotations.FirAnnotationUtilsKt.annotationsByClassId(firAnnotationUtils.kt:60)
at org.jetbrains.kotlin.analysis.api.fir.annotations.FirAnnotationUtilsKt.annotationsByClassId$default(firAnnotationUtils.kt:46)
```
^KT-57424 Fixed
- 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.
- 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
so the check is functionally the same as in K1.
#KT-57064 fixed
#KT-57065 fixed
One of the tests introduced here (javaMappedCtors) revealed an
additional issue, filed as KT-57368
The idea of the fix is just unwrapping flexible version of type alias,
before creating a not-nullable version for safe-call subject.
Otherwise, it was remained to be JsExpressionResult after applying
makeConeTypeDefinitelyNotNullOrNotNull (and the type is still nullable)
^KT-57190 Fixed
During implicit body resolve phase, we can encounter a reference to a
not yet resolved Kotlin class that inherits a synthetic property from a
Java class. In that case, resolve the return type in
FirSyntheticPropertiesScope.
#KT-57166 Fixed
Those classes mainly include KotlinCoreEnvironment and its dependencies
This change is needed for two reasons:
1. Splitting of some common configuration of compiler from logic of CLI
makes code structure more clean
2. There is a need to add dependency on `:analysis:analysis-api-standalone`
to `:compiler:cli`, because FIR analogue of AnalysysHandlerExtension uses
services from it. But the problems is that standalone AA itself depends
on classes for compiler configuration, which leads to circular
dependency between those modules. Extracting configuration to
`:compiler:cli-base` solves the problem
Kirill Rakhman