Here is the reasoning behind that change:
Historically, all the declarations generated by compiler plugins
were marked with `SYNTHESIZED` member kind in Kotlin Metadata
by K1 compiler.
In K1 IDE, descriptors were deserialized directly from the Kotlin
Metadata, and they saw all the generated declarations from it.
In the stubs, however, such declarations were not materialized at all.
It caused no troubles, since K1 IDE relied on descriptors to get the
essential resolution information in completion and other subsystems.
So, the resolution of members from jars processed
by compiler plugins (e.g. `kotlinx-serialization-json`) was mostly fine.
In K2 IDE, however, we use stubs to "deserialize" FIR declarations from
them, to later create `KtSymbol`s upon that FIR.
If we see a library file which was processed by compiler plugins, we
build stubs for it based on the Kotlin Metadata, and then use stubs to
create FIR.
But if stubs do not contain information about the generated
declarations,
then the resulting FIR will also not contain such declarations.
In the end, the K2 IDE would also be blind to such declarations, since
there is no other way to retrieve them from the library jar.
By meterializing all the synthethic declarations in stubs (with some
minor exceptions for data classes), we would avoid such problems,
and the resolve of such declarations from compiler jars in
K2 IDE would become possible.
Important note: currently, the Kotlin Metadata format between K1 and K2
frontends is not 100% the same; most notably, in K2, the generated
declarations are marked as regular declarations,
not as `SYNTHESIZED` ones.
Hence, if you compile a jar with the current version of K2 frontend,
then all the generated declarations would have a regular `DECLARATION`
origin, and there would be no such issues as described above.
There are two notes here:
1. K2 IDE still has to support the jars compiled by the K1 compiler,
so it still makes sense to alter the stubs and make the generated
declarations visible.
2. The issue about the different stub formats has been reported
(see KT-64924), and might be resolved in the future.
So it is possible that K2 frontend's metadata will also start
marking the generated declarations as `SYNTHESIZED`.
^KT-64808 Fixed
It should have been already implemented as intrinsic in all backends.
Do not test enumEntries intrinsic in the old JVM BE.
KT-53154
Co-authored-by: Alexander Udalov <alexander.udalov@jetbrains.com>
When using DeepCopyIrTreeWithSymbols as class transformer to transform
the IrClass, the source element of IrClass was set to
SourceElement.NO_SOURCE after the transform.
^KT-65343 Fixed
Before this commit, the expect-actual resolver could find expects in
regular dependencies
Note: The appeared `VIRTUAL_MEMBER_HIDDEN` in
compiler/fir/analysis-tests/testData/resolveWithStdlib/multiModule/FakeOverrides.kt
isn't caused by my change. It's caused by fixing the testData dependency
syntax notation.
The testData improperly used regular dependency syntax notation, while
it should have been using dependsOn
Before:
Regular dependency syntax notation
// MODULE: androidMain(commonMain)
After:
dependsOn dependency syntax notation
// MODULE: androidMain()()(commonMain)
`originalCallee` is supposed to be the owner of the original call.
It can be a fake override, and in the inliner we are using actual
function with body. Apparently we can just stick with the resolved
function.
#KT-64807
The previous one was incorrect for K1 since parent of top-level function
is `IrClass`, not `IrPackageFragment`.
The change is non-functional, K1 still worked correctly, but had to do
some extra work when inlining `emptyArray` calls and produces less
performant bytecode.
It was a workaround for case, where expect class don't have
override of abstract function. We don't allow it anymore,
so it can be dropped to make correct modality comparation.
^KT-65971
This fixes some crashes on red code in diagnostic tests.
Also can be useful in the future, when we would allow things like
enum.name in annotation arguments.
^KT-65971
Otherwise, when analyzing
`PsiTypeParameterListOwner` in the
related test, we (after flattening and
`nonSubsumed()`) get 2 `JvmMember.accept`
from the same very java enhancement
scope `JvmMember`.
^KT-65972
After this change the IO created for
`SimpleColoredComponent::setToolTipText`
will be `containsMultipleNonSubsumed == true`
while IOs created for classes in
`intersectionOverridesIntersection.kt`
will have this property set to `false`.
^KT-65972 Fixed
Allow multiple bases with default
implementations as long as there's a
non-abstract symbol from a class.
Our rules for Kotlin are stricter than
those in Java.
Check all members for `Visibility.Unknown`,
otherwise we miss them when they come
from supertypes. This is the reason why
the FP intellij build failed with a
cryptic stacktrace instead of a
human-readable diagnostic.
Also, do report the diagnostic at all
cases of `Visibilities.Unknown`. Turns
out, there are no "simple to reason
about" situations here :(
Also, an interesting detail:
`retrieveDirectOverriddenOf` returns an
empty list for intersection overrides.
But this doesn't seem to break anything...
Replacing `CANNOT_INFER_VISIBILITY`'s
type `KtDeclaration` with
`PsiNameIdentifierOwner` and the related
changes in `PositioningStrategies`
were needed to prevent an exception saying that
`PsiClassImpl` is not a subtype of
`KtDeclaration`.
This code does lead to inferring
`Visibilities.Unknown`, but it's not
reported anywhere. This is because it
happens inside `AbstractIntSet` which
comes to us "pre-compiled" by javac,
whereas `FirOverrideChecker` only checks
members within `KotlinClass`.
^KT-65972
The rule of thumb is the following:
If the `if` and `when` can be successfully replaced with `while`,
then it is used as a statement, otherwise, it is used as an expression.
#KT-59883
All existing tests use custom test data for FIR because the diagnostic
text in FIR has to have a dot at the end. Also, the K2 checker doesn't
check usages in imports because there are no "import checkers" in K2
right now, this will need to be fixed later if necessary.
#KT-60797 Fixed
Previously @EnhancedNullability for IR type was added if only there wasn't
an @FlexibleNullability annotation, which is inconsistent with K1
behavior
^KT-65302 Fixed
In some cases we transform flexible type into non-flexible during
enhancement, but don't add `@EnhancedNullability` attribute to them,
which breaks consistency with K1 on IR level
This commit fixes it
^KT-65302
Fix some unresolved supertypes. This is necessary to be able to enable
IR fake override builder by default (KT-61514), because it traverses all
supertypes and asserts that they're classes, so that it can build fake
overrides for declarations from there. Without this change, for example
`IrFakeOverrideBuilder.buildFakeOverridesForClass` would crash.
Kirill Rakhman