^KT-57858 Fixed
Remove FirEmptyOverridesBackwardCompatibilityHelper since it's not used anymore
Remove overridesMemberWithPlatformDependent.kt test file since it becomes redundant
This fixes a false positive OVERRIDING_FINAL_MEMBER caused by a
package-private member in a different package being added to the
list of overridden symbols. However, in Java, package-private members
from different packages are effectively like private members in that
they cannot be overridden.
#KT-61696 Fixed
^KT-61640 Fixed
This change doesn't affect any tests in the moment, because it's part of
bigger refactoring of proper storing IR declarations during FIR2IR
conversion (KT-61637)
Without this change, there is one test break in branch for KT-61637:
- FirPsiBlackBoxCodegenTestGenerated.Multiplatform.K2.testJavaMethodWithTypeParameter
This is needed for two reasons:
1. common and platform modules are analyzed in the same setup with same
dependencies and configurations, so the results of the enhancement for
any function will be completely identical. So by sharing enhanced
symbol storage, we avoid recomputation enhanced functions and improve
performance
2. There is a goal to have some unique key for IR declarations in FIR2IR.
For regular declarations, the key is just Fir symbol, and for fake-overrides
it is a pair of original symbol and fake override owners lookup tag.
But for enhanced functions the symbol is not unique, because we create
different symbols for the same enhanced function for different modules.
So this change fixes this problem
^KT-60397 Fixed
This change doesn't affect any tests in the moment, because it's part of
bigger refactoring of proper storing IR declarations during FIR2IR
conversion (KT-61637)
Without this change, there are some test breaks in branch for KT-61637:
- FirPsiBlackBoxCodegenTestGenerated.Multiplatform.testStarImportOfExpectEnumWithActualTypeAlias
- FirPsiBlackBoxCodegenTestGenerated.Multiplatform.K2.DefaultArguments.testNestedEnumEntryValue
- FirPsiBlackBoxCodegenTestGenerated.Multiplatform.K2.Basic.testEnumEntryNameCall
Originally it was named createModuleFragmentWithSignaturesIfNeeded, because
there was a counterpart `...WithoutSignatures`. Now that function has
gone and there is only one entrypoint left
Let ConeCompositeConflictResolver pass the results of the previous
resolver to the next one.
Otherwise, we get false positive conflicts when a set of candidates
can't be fully reduced by one resolver but could be resolved by the
subsequent application of multiple ones.
This change makes ConeCompositeConflictResolver order-dependent and
thus, ConeOverloadConflictResolver must be invoked last, because it
must work on a pre-filtered list.
Also, let ConeEquivalentCallConflictResolver use
FirStandardOverrideChecker instead of compareCallsByUsedArguments
because it's stricter.
This all fixes a false positive overload resolution ambiguity in common
metadata compilation that is caused by stdlib using the new KMP
format.
Now stdlib metadata is in the classpath, and so declarations from the
stdlib are returned from both MetadataSymbolProvider and
KlibBasedSymbolProvider.
This isn't a problem per se because duplicate candidates are filtered
out by ConeEquivalentCallConflictResolver (K1 works analogously), but
in the case of top-level functions with generic receivers like
Collection<T>.toTypedArray, the check failed because of the direct
comparison of receiver types.
#KT-60943 Fixed
- Rename DeserializedClassConfigurator -> FirDeserializationExtension to
abstract the existing behavior (about the Serializable supertype), as
well as any future JVM-specific deserialization behavior.
- Rename JvmDeserializedClassConfigurator ->
FirJvmDeserializationExtension and move it to fir:java.
This is needed to be able to precisely distinguish different synthetic
declarations (like fields for delegates and functions for data classes)
in fir2ir
This will be needed in subsequent commits because context must be
accessible from `:fir:checkers` module, but it is in `:fir:resolve`
Intermediate interface `FirExpectActualMatchingContext` is needed
because `FirExpectActualResolver` relies on some FIR-specific methods,
and providing common `ExpectActualMatchingContext` interface is not
enough.
Also in `FirExpectActualMatcherTransformer` context extracted to field
to not create context for each processed element. "session" made
final to calm down warning "accessing non-final property in
constructor".
^KT-58551
cinterop tool should add ExperimentalForeignApi to all generated
declarations, to indicate their experimental status and discourage using
them in public Kotlin API. But the same considerations are applicable
to forward declarations (cnames.*, objcnames.*), which are generated not
by cinterop tool, but directly by the compiler.
This commit adds ExperimentalForeignApi to those compiler-generated
classes.
^KT-58362
Support CALL_TO_JS_MODULE_WITHOUT_MODULE_SYSTEM diagnostic
^KT-59377 Fixed
Support CALL_TO_JS_NON_MODULE_WITH_MODULE_SYSTEM diagnostic
^KT-59381 Fixed
Support CALL_FROM_UMD_MUST_BE_JS_MODULE_AND_JS_NON_MODULE diagnostic
^KT-59417 Fixed
This is refactoring in preparation for KT-59764.
Names and layout of forward declarations related classes
was copy-pasted many times over compiler code.
Implementing KT-59764 would require copy-pasting it two more times.
So instead of doing this it was put in single place.
No behaviour changes intended in this commit.
Previous approach prevented double registration of the plugins, but
might have caused a race condition: atomic flag was set before the
plugins initialization, not after, so another thread could see garbage
data even if it could read the flag set to "true".
This might or might not be a root cause for the KTIJ-24983 exception,
so we'll have to wait for some time before actually closing the issue.
According to
`FirNativeCodegenBoxTestGenerated.testNestedClassesInAnnotations`,
the annotation
`kotlin.internal.PlatformDependent` is
unresolved reference.
^KT-58549 Fixed
- In LL FIR, we have increasingly formalized symbol name caches as
palpable objects. The main reasons for this formalization were the
need to share implementations of caching between different (LL FIR)
symbol providers, the need to build composite name caches from
individual name caches, and the introduction of resolve extensions
which may provide additional declarations and thus complicate the name
set construction for Kotlin symbol providers in LL FIR.
- `LLFirSymbolProviderNameCache` also shared a lot of similarities with
cache handling in FIR providers like
`FirCachingCompositeSymbolProvider` and
`AbstractFirDeserializedSymbolProvider`.
- This commit introduces a `FirSymbolNamesProvider` as a component of
`FirSymbolProvider`. This symbol names provider's task is to provide
the sets of names which `FirSymbolProvider` previously provided. It
also allows sharing implementations of `mayHaveTopLevel*` once and for
all, which is an improvement over the previously scattered
implementations (the same ideas replicated many times throughout
different symbol providers).
- `FirSymbolNamesProvider` by design doesn't cache, as many symbol
providers may not need such a cache. `FirCachedSymbolNamesProvider`
can be used to cache symbol names if needed. The symbol name provider
architecture also makes it easier to switch between caching and
non-caching, without the need to reimplement caches every time.
- Synthetic function types complicate the picture, but this complication
is now exposed with the rest of the API, instead of being hidden in a
few implementations here and there. This allows symbol providers to
more explicitly state whether they can provide generated function
types, which is an advantage for the correctness of composite symbol
providers.
Some specific notes:
- In `FirSyntheticFunctionInterfaceProviderBase`, the class ID check has
been replaced with a full `mayHaveTopLevelClassifier` check so that
the cache doesn't get filled with `null` entries.
- `LLFirKotlinSymbolProviderNameCache` is turned into a non-caching
`LLFirKotlinSymbolNamesProvider` so that this symbol names provider
and those of resolve extensions can be composed into one caching
symbol provider in `LLFirProviderHelper` without creating layers of
caches. If the Kotlin symbol names provider was caching out of the
box, `LLFirProviderHelper.symbolNameCache` would cache the
names (1) in the combined symbol names cache and (2) in the Kotlin
symbol names cache.
- A caching Kotlin symbol names cache can still be created easily with
the `LLFirKotlinSymbolNamesProvider.cached` constructor function.
Previously, the semantic was more-or-less correct for most of the cases
but some corner one, like `sort` in MutableList didn't work properly.
Namely, `sort` should be marked there in a way to forbid to call it
everywhere beside super-calls.
Also, overriding it should be allowed.
Mostly, the logic was re-written to K2 model from K1-related
JvmBuiltInsCustomizer.
^KT-57694 In progress
^KT-57269 Fixed
> Condition 'isSuspendFunctionType' is always false when reached
The change in the native tests is needed, because K2
doesn't support disabling old language features
^KT-58623 Fixed
In this example we get 2 variants of `kotlin/toString()`:
one coming from the KLib provider, and the
other coming from the builtins provider.
These are identical deserialized functions.
^KT-57601 Fixed
Ivan Kochurkin