^KT-59297 Fixed
'ProcessCancelledException's are commonly thrown during code analysis,
yet not every place is ready for them. As a FIR tree is a mutable data
structure with no transaction support, sporadic halts during its
mutation might easily leave it in an inconsistent state.
Before this change, whole module sessions (with all dependents) were
invalidated if an exception occurred during their analysis. Not only it
was very ineffective, it also resulted into a concurrency problem.
'ProcessCancelledException's are thrown when an underlying progress
indicator is invalidated. As analysis in each thread might have its own
progress indicator, invalidation in one thread should not stop
analysis in others. However, it is impossible in the current state,
as all threads share the same FIR tree structure.
The change introduces 'FIR guards' – a set of instructions defining
preservation and restoration rules for individual state items. As each
resolution phase is supposed to modify only a (sort of) known subset
of tree elements, restoration of potentially changed state on a failure
effectively returns the tree consistency.
Note that guards are not defined for certain phase transformers. The
reason is that the transformers already update the tree content safely.
E.g., the type reference is updated once it is resolved, and already
resolved type references are either resolved the same way again, or
just skipped on consequent phase runs.
JUnit5 combines tags and then applies to this combined list filters from
the test task. If this list contains any excluded tag - test will be
ignored.
^KT-59587 In Progress
Add a new method `isImplicitReferenceToCompanion` to determine
if the given reference is an implicit reference to a companion object.
The method is needed for the rename refactoring in IJ.
^KTIJ-25863
... as well as $SwitchMap and other synthetic classes generated by javac
or other JVM language compilers or runtimes.
Note that for Kotlin, all synthetic classes were already handled by the
subsequent check for `KotlinClassHeader.Kind.SYNTHETIC_CLASS`, but after
this change we won't call `ReflectKotlinClass.create` for those, which
is a minor optimization.
#KT-41373 Fixed
... for Kotlin-generated classes which do not correspond to a "class"
from the Kotlin language's point of view. For example, Kotlin lambdas,
file facade classes, multifile class facade/part classes, WhenMappings,
DefaultImpls. They can be distinguished from normal classes by the value
of `KotlinClassHeader.Kind` (which is the same as `Metadata.kind`).
Another theoretical option would be to throw exception at the point
where the `::class` expression is used, if the expression's type on the
left-hand side is a synthetic class. But we can't really do that since
it'll affect performance of most `<expression>::class` expressions.
So, construct a fake synthetic class instead, without any members except
equals/hashCode/toString, and without any non-trivial modifiers. It kind
of contradicts the general idea that kotlin-reflect presents anything
exactly the same as the compiler sees it, but arguably it's worth it to
avoid unexpected exceptions like in KT-41373.
In the newly added test, Java lambda check is muted but it should work
exactly the same as for Kotlin lambdas and other synthetic classes. It's
fixed in a subsequent commit.
#KT-41373 In Progress
Local classes and anonymous objects are normal classes and
kotlin-reflect can load all declarations and modifiers from them, and
support calling members, exactly in the same way as it does for normal
non-local classes.
#KT-41373 In Progress
kotlin-reflect works correctly already for Kotlin-generated local
classes and anonymous objects, but not for Java ones. This is fixed in a
subsequent commit.
#KT-41373 In Progress
This utils are intended to be used external target authors exclusively
and shall help to create sources.jar files using regular
Kotlin Multiplatform conventions.
^KT-58109 Verification Pending
Note that call-site class has no metadata for inlined local delegated
properties. Thus, for an inlined local delegated property we should
obtain declaration-site class as owner - otherwise, the corresponding
`PropertyReference` will have an owner without property metadata.
Yan Zhulanow