This origin was set somewhat arbitrarily.
It actually only makes sense for `IrCall`s to property getters.
There were no places in lowerings that checked `IrGetField` expressions
for this origin value.
^KT-62500 Fixed
At the moment, SubclassOptInRequired is marked with the
ExperimentalSubclassOptIn annotation. However, it does not work
as expected due to a missing opt-in error. To use SubclassOptInRequired,
an explicit opt-in is necessary because SubclassOptInRequired is an
unstable feature now.
^KT-64739
In before, actualizer was copying attributeOwnerId to new
nodes. This leads to attributeOwnerId linked to non-actualized
node. It's unclear what it leads to, so we just stop doing that.
In particular, if attributeOwnerId references another node,
this information would be lost.
^KT-64895
...instead of those computed from a frontend representation
(`symbol.signature`).
This is more robust; besides, we are going to turn off building
signatures from FIR, so `symbol.signature` is going to return null soon.
The error-level enhancement is kept as warning-level and a new
LanguageFeature is introduced to turn the warning into an error.
#KT-63208 Fixed
#KT-63209
This is required for EnhancedTypeForWarningAttribute because scopes
should not be reused between cone types with different values of
this attribute.
#KT-63208
Previously, if the parent class was in Java code and the subclass in
Kotlin, the opt-in usage error would not be reported for the subclass.
The problem was that the extractClassFromArgument function couldn't get
the class type from Java code. It was looking for a ConeClassLikeType,
but found a ConeFlexibleType instead.
#KT-60258 Fixed
```
abstract class Base
var x: Int
private set
}
class Derived : Base()
```
Without this change, FIR2IR created a symbol for setter of f/o Derived.x,
but IR f/o generator doesn't create a setter in f/o, as this setter is
invisible in Derived
^KT-64742
Now, we detect clashing signatures during serialization to KLIB and
report a compiler error if two or more declarations have the same
`IdSignature`
For example, for the following code:
```kotlin
@Deprecated("", level = DeprecationLevel.HIDDEN)
fun foo(): String = ""
fun foo(): Int = 0
```
the compiler will produce this diagnostic:
```
e: main.kt:1:1 Platform declaration clash: The following declarations
have the same KLIB signature (/foo|foo(){}[0]):
fun foo(): String defined in root package
fun foo(): Int defined in root package
e: main.kt:4:1 Platform declaration clash: The following declarations
have the same KLIB signature (/foo|foo(){}[0]):
fun foo(): String defined in root package
fun foo(): Int defined in root package
```
Note that we report this diagnostic during serialization and not earlier
(e.g., in fir2ir) for more robustness, so ensure that we check
exactly the signatures that will be written to a KLIB.
If we later introduce some annotation for customizing a declaration's
signature (e.g., for preserving binary compatibility), this
diagnostic will continue to work as expected.
^KT-63670 Fixed
To reuse this diagnostic reporter in `serialization.common` for
reporting signature clashes (KT-63670), we must extract it to
the `serializeModuleIntoKlib` method instead of creating it in
`JsKlibCheckers`.
However, because `serialization.common` does not depend on
the `backend.common` module in which
`KtDiagnosticReporterWithImplicitIrBasedContext` is declared,
we have to use the `IrDiagnosticReporter` interface in place of
`KtDiagnosticReporterWithImplicitIrBasedContext`.
Besides, it's better from the architectural point of view:
the users of that diagnostic reporter should not know about its
implementation details.
Otherwise, these tests fail due to
misplaced diagnostics in LT:
- `testExtensionFunctionArgumentOrReturnType`
- `testInlineClassAsParameterOrReturnType_allowed_kt`
- `testInlineClassAsParameterOrReturnType_kt`
Otherwise, it's reported for `d += 1`
instead of `+=`, but since we only
render `DEBUG_INFO_DYNAMIC` if there's
already one at exactly the same
location, we effectively just lose
some of the existing ones.
Ivan Kylchik