Otherwise, such types are treated as resolved, but anyway
requires transformation on type phase.
Also, this commit drops the redundant duplicated transformation of
typeReference from primary constructor property generator
^KT-61422
Previously filecheck_signext_zeroext_objc_export test was disabled
after making one-stage compilation mode implemented through two-stage
mode (KT-59245).
That change made the compiler sort the methods, and filecheck patterns
didn't match that order after that.
This commit fixes the test by adding sorted prefixes to method names,
so sorting alphabetically them doesn't really change the order.
There was a minor mistake in the build script configuration, leading to
a missing task dependency when running the tests with
`-Pkotlin.native.home=`.
More specifically, the build script was checking if the cross-dist for
the main tests target (`-PtestTarget=`) is in place, but instead it
should have checked if the cross-dist for the test cross-target
(`test.targetName`) is in place.
This commit fixes the check, and thus adds the missing task dependency.
- Previously, `KtFirAnonymousObjectSymbol` was a
`KtEnumEntryInitializerSymbol`, which carried the risk that an
anonymous object unrelated to enum entries might be used as an enum
entry initializer. This commit introduces a specific symbol for FIR
enum entry initializers.
- As a nice side effect, anonymous object symbol creation is simplified
and `KtFirEnumEntryInitializerSymbolPointer` can restore the symbol
via `KtFirEnumEntrySymbol.enumEntryInitializer`.
^KT-61425
- Now that the enum entry initializer provides a member scope, not the
enum entry, we need a way to get to the enum entry initializer in
tests. This can only be done via the enum entry's name, because the
initializer is anonymous.
^KT-61425
- An enum entry's body is an initializer with members only accessible
within that body. Because users of the Analysis API might want to
analyze the members of the enum entry initializer, we expose this
initializer via `KtEnumEntrySymbol`. The initializer only exists if
the enum entry has a body.
- We already have some usages of the initializer inside symbol light
classes, which generate a light class for each enum entry, which
includes the enum entry's hidden members.
- To hide the implementation detail that initializers are anonymous
objects, `KtEnumEntryInitializerSymbol` is simply a
`KtSymbolWithMembers`.
- The advantage of making it a `KtSymbolWithMembers`, instead of
providing a custom way to get a member scope, is that we can pass
around the initializer easily, e.g. in `KtEnumEntrySymbolRenderer`.
- We implement `KtEnumEntryInitializerSymbol` directly as a
`KtFirAnonymousObjectSymbol` without a wrapper. This has a few
advantages:
1. We can directly benefit from the anonymous object symbol being a
`KtSymbolWithMembers`, so we don't have to handle enum entry
initializers specially in e.g. `KtFirScopeProvider`.
2. We don't have to implement a new symbol restoration mechanism for
the initializer.
3. This implementation matches the actual FIR tree structure (with a
simplification that the connecting anonymous object expression
between the enum entry and the initializing anonymous object is
omitted).
^KT-61425 fixed
- An enum entry is a variable which doesn't declare any additional
members. It must not be confused with its implementing anonymous
object initializer, which may declare additional members, but is an
implementation detail hidden outside the enum entry's initializer.
Hence, the enum entry variable should not have a (declared) member
scope.
- A following commit will add the ability to get the enum entry's
initializer, so that a member scope for this initializer can be
obtained (which might be relevant for local analysis).
^KT-61405 fixed
- The implementations of some FIR scopes contain a significant amount of
delegation to some original scope. This pollutes the implementation of
such scopes and makes them harder to read.
`FirDelegatingContainingNamesAwareScope` and `FirDelegatingTypeScope`
can be used as base classes which delegate by default.
Fix an issue where an inherited @JsName from
another module was not accessible in a child class.
The issue can only be reproduced in the codegen box tests
and cannot be reproduced in the FIR FE checker tests.
Dmitrii Gridin