K1 implementation of kotlinx.serialization used SerializationPluginMetadataExtensions
for two purposes:
- to extract the source-order of properties
- to identify which properties are actually serializable
In K2, the first point is covered by the compiler itself (as it correctly orders
properties during deserialization), and to cover the second point we
need to save in the propery information if it was mentioned in this extension
or not
KT-64312
StandardClassIds was using Annotations subclass in its initialization.
At the same time, Annotations subclass was using StandardClassIds in its
initialization implicitly through baseId() method.
This leads to a rare deadlock on CI in case where two different threads
tried to initialize both classes at the same time.
It can't be reproduced robustly, as a single thread was able to
successfully initialize both, and will do it on an attempt to
initialize any of them.
^KT-64720 Fixed
During refactoring of FIR2IR commit 8ebb4127 introduced
`FirProviderWithGeneratedFiles` for lookups for containing FIR for
generated declaration
But it broke the logic of `Fir2IrIrGeneratedDeclarationsRegistrar`,
which provides annotations for metadata from generated IR annotations
(see `containingFile` function in it), as it started to use fir
provider from the platfrom session instead of provider of the
corresponding session
So to fix this issue `FirProviderWithGeneratedFiles` was changed in the
way so it sees declarations from dependant sessions too (only with
`dependsOn` relation), which allows to use provider for the leaf
platform session for declarations from any module within the same
HMPP hierarchy
^KT-64444 Fixed
Utilize `FirSamResolver` to obtain the potential SAM constructor
from the classifier
Also, accept K2_SYNTHETIC_RESOLVED in the `resolveUnqualifiedAccess`,
since this is the kind of resolve success which corresponds to the
SAM constructor call resolution
^KTIJ-28167 Fixed
This allows to properly report them as used in `KtFirImportOptimizer`
This change will also be important for properly fixing KTIJ-28167,
since `computeImportableName` is also used in reference shortener
^KTIJ-28385 Fixed
Class properties are being expanded before checking for custom
parcelers, which makes custom parcelers of type alias unable to be
found. To maintain K1 behavior, the custom parceler type must also be
expanded, so even the aliased type is supported when used in its raw
form as a class property.
^KT-64707 Fixed
Java resolving subsystem requires calculated visibility for correct disambiguation of supertypes.
But visibility remains `Unknown` for Kotlin class-like declarations during supertypes resolving because `STATUS` resolve phase is performed after `SUPER_TYPES` phase.
To fix the problem, the visibility should be initialized to public at the FIR building phase if no modifier is presented.
^KT-64127 Fixed
We don't have true flexible types in the IR, but we approximate it with
internal type annotations, such as FlexibleNullability,
FlexibleMutability, RawType. These annotations are then handled
specially in JvmIrTypeSystemContext, which can construct a fake flexible
type so that type checker on IR types would behave exactly as on
frontend types.
As shown in KT-63441, one instance of flexible types where flexibility
was lost during conversion to IR is Java array/vararg types. It's
necessary to support it so that IR fake overrides could be constructed
correctly, because IR fake override checker requires parameter types to
be equal. So this change introduces another internal type annotation,
FlexibleArrayElementVariance, which is only applicable to types with
classifier kotlin/Array, and which signifies that the annotated type
`Array<X>` should rather be seen as `Array<X>..Array<out X>`.
#KT-63441 Fixed
#KT-63446 Fixed
When performing lookahead for local variable assignments, make sure
assignments taking place within loops are being propagated before loops.
This makes sure smartcasts within non-inline declarations before the
loop are disallowed.
^KT-63867 Fixed
findClasses works over regular `PsiElementFinder`, which doesn't know
about out ClassId conception. So, `a/b/A.B` and `a/b/A/B` are the same
from `FqName` point of view.
`FirJavaFacade` has this check, so this problem appears only in the case
of combined provider.
^KT-62892 Fixed
Previously we just skipped Java sources.
The order of classes in light classes test data is changed due to
differences in implementations of `compileLibraryToJar` and `runJvmCompiler`
^KT-62892
In this commit, .ir.txt expectation test data files for the JVM IR
backend are renamed to .txt. This is done as two separate commits so
that Git would recognize that these files were logically moved, not that
the contents of the original .txt files were changed.
#KT-64680
Dmitriy Novozhilov