Previously, creating a declaration with Fir2IrCallableDeclarationsGenerator/
Fir2IrClassifiersGenerator didn't guarantee that this declaration will
be actually added to the list of parent class/file declarations, which
lead to situations when FIR2IR created some declarations in the air
(mostly fake-overrides)
It is needed to have an ability to distinguish those two cases in FIR2IR:
Without this change the following tests fail:
- org.jetbrains.kotlin.test.runners.codegen.FirPsiBlackBoxCodegenTestGenerated.Enum
- testEnumEntryReferenceFromInnerClassConstructor1()
- testEnumEntryReferenceFromInnerClassConstructor2()
- testEnumEntryReferenceFromInnerClassConstructor3()
- testInnerClassMethodInEnumEntryClass()
- testInnerClassMethodInEnumEntryClass2()
- testKt9711_2()
- testDeepInnerClassInEnumEntryClass()
- testKt7257_boundReference1()
- testInnerClassInEnumEntryClass()
- testKt44744_innerClass()
For reasoning refer to the message of the previous commit
It is the same as for `getIrFunctionSymbol`
There is one failing test here, caused by KT-61941
The issue was here before this commit, but it was hidden
It's incorrect to create fake-overrides with `getOrCreateIrFunction/Property`
call. FakeOverrideGenerator should be used instead. So this commit
just changes the place which creates static f/o generated from
I failed to reproduce the corresponding failure in compiler tests, but
without this change FP Kotlin test fails
Previously `getIrFunctionSymbol` effectively did the same thing as `getOrCreateIrFunction`,
but in a slightly different way. To avoid logic duplication and source of
potential inconsistencies, implementation was changed to just delegate to
`getOrCreateIrFunction`
Changes in `computeIrOrigin` were required because origin for callables in
`getOrCreateIrFunction` and `getIrFunctionSymbol` was computed differently,
so `computeIrOrigin` was changed to preserve existing behavior
^KT-60924
This change is intended to improve the intuition of developers.
After adding the two functions, many times developers (me) have
tried to use the 'wrong' (which is now the new name) function name.
KT-61634
https://youtrack.jetbrains.com/issue/KT-59916/K2-Disappeared-REPEATEDANNOTATION
FirAnnotationChecker does not detect repeated annotation on dynamic type, since FirTypeResolverImpl wrongly did not convert source annotations to attributes of ConeDynamicType.
This MR improves FirTypeResolverImpl to convert attributes of FirDynamicTypeRef to annotations and attach them to ConeDynamicType.
Merge-request: KT-MR-12551
Merged-by: Vladimir Sukharev <Vladimir.Sukharev@jetbrains.com>
This flag will be used on JVM to determine whether or not to generate
external enum entries mappings ("$EntriesMappings") classes. Note that
from the frontend's point of view, every enum has `entries`, so for
backend purposes we have to reach out to the underlying deserialized
data to read the flag from the metadata.
The enumEntriesIntrinsicMultipleEnums.kt test was supposed to check that
JVM backend generates 3 `$EntriesIntrinsicMappings` classes: for X, for
Y, and for Z. Mappings classes are generated for enums without
`entries`, i.e. Kotlin enums compiled without `EnumEntries` language
feature, and Java enums. The test incorrectly _enabled_ the language
feature for X though, and `$EntriesIntrinsicMappings` for X was
generated anyway because of KT-61208.
To keep the original intention of the test, I'm disabling the language
feature for X, so that it will be considered as enum without `entries`.
KT-61208 will be fixed in a separate commit (with separate tests).
The boxInline and bytecodeText tests changed their meaning when language
feature EnumEntries started to be enabled by default, so those changes
are a continuation to ebd43fc8c0. The behavior did not change after
enabling the feature, once again because of KT-61208.
Also, remove obsolete error suppressions which are no longer needed
after 64c8ce18a0.
If you want to shorten call like `foo.bar()` into `bar()`, then you
need your range to intersect with `bar` callee reference. Having only
`foo` in the range is not enough
Same goes for the type references - to shorten `foo.Bar` into `Bar`, you
need at least some intersection of your range with `Bar` reference
^KTIJ-27139 Fixed
^KTIJ-27015 Fixed
In commit 4e89dcf, we removed `flush()` from `PersistentStorage`
(previously called `LazyStorage`) because it is not used in Gradle
builds.
However, `flush()` is still used in JPS builds, so we need to add that
API back in this commit.
#KT-62486 Fixed
Co-authored-by: Hung Nguyen <hungnv@google.com>
Merge-request: KOTLIN-MR-796
Merged-by: Aleksei Cherepanov <aleksei.cherepanov@jetbrains.com>
It's effectively a breaking change (^KT-62558)
K2 assigns flexible type to all static fields (from Java) and, for example,
`String? becomes String unlike K1. It affects IR signature generating.
That's why signature dump is disabled for some tests.
^KT-57811 Fixed
^KT-61786 Fixed
`AbstractSet` is a java class, and it brings flexible types with it.
Because of it, it was possible to write the following code:
```kt
fun usage() {
val mySet = SmartSet.create<String>() // should not contain nulls
mySet += null // compiles because of flexible types
}
```
Using `AbstractMutableSet`
as a base class does not change the implementation,
but explicitly adds a proper kotlin `MutableSet`
interface to the class, making it more type-safe
Such properties should be stateless and just wrap over accessories.
Logic inside contract transformer is unreachable because we do not
allow lazy resolution for synthetic properties.
^KT-61990
See the comment in the code for more info.
No proper test added because the compiler test infrastructure lacks the
ability to run old compiler versions, however I've verified manually
that the change fixes the issue.
#KT-62531 Fixed
Reporting of those errors was implemented as an ad-hock solution for part
of the KT-58881, and it was implemented incorrectly. There won't be any
need in this reporting in actualizer after KT-58881 will be fixed, so
there is no actual sense to fix their implementation in actualizer itself
(as it will be removed)
In Kotlin subclasses of `MutableCollection<Int>`, the method
`remove(Int)` has its argument boxed, so that it wouldn't clash with the
method from `java.util.List`. So `JavaOverrideChecker` should understand
that a Java method `boolean remove(java.lang.Integer)` overrides it,
otherwise platform declaration clash was reported.
The code is adapted from `forceSingleValueParameterBoxing` in K1's
`methodSignatureMapping.kt`.
The test has been moved and adapted from diagnostic to codegen box
tests, to check correct backend execution + runtime.
#KT-62316 Fixed
Dmitriy Novozhilov