Deduplicate Fir2IrExtensions creation and move the
convertToIrAndActualizeForJvm function to 'cli', which allows to remove
the dependency of 'fir.entrypoint' on 'backend.jvm'.
Note that behavior slightly changes in IncrementalFirJvmCompilerRunner:
previously the value of linkViaSignatures was always false, now it is
taken from the compiler configuration, which seems more correct.
- This is more consistent with "top-level callable names in package" and
simplifies the set construction quite a bit, as we can avoid a lot of
`asString` conversions.
^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.
Kirill Rakhman