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, `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.
After the fix for the KT-60904 issue (c963eadb),
there are unnamed declarations created even for
the unused variables in destructuring declarations
Because of this, we can actually align testData
for K1 and K2. It seems like KT-59504 is no
longer relevant and can be marked as obsolete
because of the KT-60904 fix
^KTIJ-26959 Fixed
See the comment at updateSubstitutedMemberIfReceiverContainsTypeVariable
It became necessary after delegate inference is rewritten, since before
that happened, stub types were being left there and FIR2IR handled
them accidentally properly because stub types are equal to anything.
But that wasn't really correct even there because stub types are not
intended to leak out of the FIR
^KT-61060
It's been changed because `getValue` might be not completed after
exiting from call transformation while contracts processing seems to be
working only with completed calls
^KT-61055 Related
The main idea is getting rid of stub types and using just type variables
See more detailed description at docs/fir/delegated_property_inference.md
The problem with stub types is that they need really special treatment
in many places, and on the other hand, there are no clear contracts on
how they should work (that regularly leads to bugs like KT-59529)
^KT-61060 Fixed
^KT-61075 Fixed
^KT-61077 Fixed
^KT-59529 Fixed
^KT-61633 Related
^KT-61618 Related
^KT-61740 Related
^KT-59107 Related
^KT-61747 Related
^KT-61077 Related
^KT-61781 Related
The original Java checker has an early return in
case of `resultingDescriptor !is JavaClassConstructorDescriptor`.
It fires if the descriptor is
`TypeAliasConstructorDescriptor`, thus further
diagnostics are not reported.
Adding these dependencies to the `api` configuration pollutes classpath for each dependant modules even if it doesn't need them. Instead, the dependencies should be declared more granularly if they're required
#KTI-1349 In Progress
To avoid collecting context which includes the implicit class receiver,
context for class header positions is collected before entering
the `context.withRegularClass` call
Note that 3 tests are still muted, but for another reason: for FIR
versions of the tests, we need to compile the "pre-release library" with
the next language version which is 2.1. But since currently
LanguageVersion.LATEST_STABLE is 1.9, the compiler refuses to read
metadata of version 2.1, regardless of its own language version. Which
is correct, but it leads to irrelevant errors in the test output -- the
ones about the incompatible metadata version, NOT about the
prereleaseness.
These 3 tests can be unmuted once the default language version is
switched to 2.0.
#KT-60780 Fixed
IllegalArgumentException: class
org.jetbrains.kotlin.psi.KtLambdaArgument is not a subtype of class
org.jetbrains.kotlin.psi.KtExpression for factory
TYPECHECKER_HAS_RUN_INTO_RECURSIVE_PROBLEM
was reported when TYPECHECKER_HAS_RUN_INTO_RECURSIVE_PROBLEM was
reported on a FirLambdaArgumentExpression, report it on its
`expression` instead.
#KT-60380 Fixed
Dmitrii Gridin