Delegated callables in FIR are session-dependant (as fake-overrides),
so it's incorrect to use their FIR as a key for declaration storage.
Pair of original function and owner lookup tag should be used instead
^KT-62671 Fixed
When files from different IrModules are merged in IrActualizer
their IrModule link was not updated. This led to assuming them
as different modules, and incorrect internal visibility handling.
^KT-62623
Previously, creating a declaration with Fir2IrCallableDeclarationsGenerator/
Fir2IrClassifiersGenerator didn't guarantee that this declaration will
be actually added to the list of parent class/file declarations, which
lead to situations when FIR2IR created some declarations in the air
(mostly fake-overrides)
Currently, there is only attribute `ExpectForActualAttributeKey`
where mapping is stored only for source declarations with `actual`
modifier. But we need mapping of all class members, including classes
which were actualized via `actual typealias` or fake override members.
This data will be needed for the annotation checker in subsequent
commits.
^KT-60668
^KT-60936
This fixes a KMP issue where IrActualizer would add duplicate
fake overrides because the parent class would have both the getter
and the synthetic property in its list of declarations.
Now, the synthetic property fake overrides are still generated and
cached in the Fir2IrDeclarationStorage, but not added to the class.
#KT-60854 Fixed
^KT-59665 Fixed
Review: https://jetbrains.team/p/kt/reviews/11039/timeline
It's better to have this logic in common place
(AbstractExpectActualCompatibilityChecker) to avoid missing compilation
errors in the future
This commit fixes:
1. Missing compilation error for actual function with default arguments
for 'actual typealias' KT-59665
2. Missing compilation error for actual function with default arguments
for actual fake-override KT-59665
Alternative solution for KT-59665 is to create a special checker.
"incompatibility" vs "special checker":
Arguments for common incompatibility:
- What if we had a rule that expect and actual default params must
match? If so then it certainly would be an incompatibility.
- Technically, we do the matching of expect and actual params (because
we allow default params in common ancestors of expect and actual
declarations).
- It's hard to check that the actual definition doesn't use default
params because `ExpectedActualResolver.findActualForExpected` filters
out fake-overrides and doesn't return them. It's not clear logic for
me, that I'm afraid to touch.
implicitActualFakeOverride_AbstractMap.kt test breaks if you drop this
weird logic
- WEAK incompatibilities can be considered as "checkers". So it doesn't
matter how it's implemented, as a "incompatibility" or a "checker"
Arguments against common incompatibility:
- Although we match expect and actual declarations to allow default
params in common ancestors of expect and actual declarations, it's
still can be considered that we check that the actual declaration
doesn't have default params. And it doesn't feel right that we check
correctness of the actual declaration in expect-actual matcher.
- ~~It may change the rules of expect actual matching~~ (It's not true,
because ActualFunctionWithDefaultParameters is declared as WEAK
incompatibility)
This change covers the case where some f/o was generated in common module
and it is referenced in platform code. But signature of this f/o may be
different in different modules because of e.g. actualization of value
parameters with actual typealias
^KT-60850 Fixed
Before this commit, we copied each type parameter during method
enhancement, while not copying the symbol. This led to symbol clashes
in MPP scenarios and various other problems.
Now we create a fully-functional type parameter copy in enhancement
and perform a substitution of old type parameters with new ones
in receiver type, value parameter types, return type,
and type parameter upper bounds.
#KT-59766 Fixed
#KT-59738 Fixed
This fixes an issue with checking for default values in call resolution
(see FirDefaultParametersResolver) where it is expected that the map
only contains a single compatible entry.
#KT-59613 Fixed
- Actualize muted K2 tests
- Actualize muted K1 tests with module systems because legacy Wasm test
infra had no respect for "// MODULE: ..." test directives
There are some cases for fake-override actualization which become
prohibited in the new expect/actual model, so few tests start to fail,
despite the fact that they are checking entirely different things
This is needed to correctly handle the case, when we have the same java
class in common and platform module. In this scenario we have two
different classes on frontend (because symbol providers are not shared)
and completely different enhanced function in scopes of those classes,
but exactly one IrClass for those classes, which is cached during
conversion of common module together with cache of its fake overrides.
So using FirDeclaration as a key to FO cache leads to the problem, when
we can not find cached value for platform module, because it has different
fir declarations for the same real decalration
^KT-58030 Fixed
It is not supposed to work with K1 on Native due to test infrastructure
limitations, and actually fails in one of the compilation modes in
nightly tests.
Nikita Bobko