- 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
^KTIJ-24638
Notice on `DebugSymbolRenderer`:
stub based deserializer sets source directly,
but it's available in IDE mode only.
Thus, standalone and IDE tests have different results.
In order to avoid this, sources for compiled code are explicitly ignored
Notice on distinct callables:
for a file which belong to multiple libraries, decompiled code would be build per library.
In order to avoid ambiguity errors for members in that file,
we need to distinct provided elements by origins
failed test from IJ repo:
FirReferenceResolveWithCrossLibTestGenerated#testSetWithTypeParameters
Introduce an extension method to retrieve the set of applicable targets
for an annotation, given the annotation class's symbol.
This extension on `KtSymbolInfoProvider` causes a large amount of churn
in test data files, so this change starts off by introducing the
property and always making it return null. A future change will
introduce the actual behavior change, and will include the testdata
changes for the few tests that actually return useful data for this
property.
Review: https://jetbrains.team/p/kt/reviews/7652
Put this change into a separate commit because:
1. The change is boring and clutters the diff of the first commit
2. The first commits is already too big
^KTIJ-23421
hide explicit builtins to reveal target platform dependencies.
Otherwise, `expect` class from builtin of e.g. JDK
would be found instead of actual dependency from Kotlin Runtime
We are going to deprecate `WITH_RUNTIME` directive. The main reason
behind this change is that `WITH_STDLIB` directive better describes
its meaning, specifically it will add kotlin stdlib to test's classpath.
Jinseong Jeon