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
Unresolved annotation arguments were treated as absent arguments,
which lead to false-positive reports.
Add assert and test for that and fix.
MR: KT-MR-12245
^KT-60671 Fixed
This includes checking of annotatins set on:
- value parameter types
- type parameter bound types
- extension functions receiver types
- function return types
- class super types
Fix in `defaultParams_inheritanceByDelegation_positive.kt`
is needed because of problem in resolution of implicit return types
(KT-62064), which leads to crash in annotation checker, because it
expects resolved return type.
MR: KT-MR-12245
^KT-60671 Fixed
if property doesn't specify explicit type,
property's return type would be calculated by provided initializer
^KT-62588 fixed
Merge-request: KT-MR-12564
Merged-by: Anna Kozlova <Anna.Kozlova@jetbrains.com>
We should process generated property as a part of the primary constructor.
This was already implemented in 8387ea8a, but some parts were missed.
ClassDiagnosticRetriever:
* dropped relation to properties generated from constructor parameters
as they should belong to the primary constructor only
* accurate logic to fully visit an implicit primary constructor to be
able to process nested declarations (e.g., inside a super type call)
SingleNonLocalDeclarationDiagnosticRetriever:
* add relation to generated properties as now they fully belong to
the constructor
FileElementFactory:
* dropped explicit resolution of generated properties from a constructor
* added explicit resolution of generated enum members for consistency.
Effectively, this is not required because we don't have compiler
checkers for such generated enum member declarations
ClassDeclarationStructureElement:
* do not collect mapping for generated properties from constructor
* explicitly declare that we should process only ClassDelegationField
^KT-62437 Fixed
Alexander Shabalin