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.
The change in PSI consistency test is needed, because
we may sometimes observe empty
`KtConstructorDelegationCall`s, and we don't want
to build delegation calls for constructors of `external`
classes with such calls.
^KT-64548 Fixed
This commit explicitly splits raw fir builder in lazy mode on
AST and stubs.
By default, in tests we have an AST tree loaded, so all our
`disallowTreeLoading` is useless in unit tests mode
^KT-64646 Fixed
^KT-64898
^KT-64899
^KT-64900
^KT-64901
Add test for other collections with (add/remove)(First/Last) methods. Add test for LinkedHashMap.put(First/Last) methods (they are also appeared in Java 21)
To separate interop modules to different packages,
.def files should be treated similarly to .kt files:
1) package directive should be prepended with test-specific synthetic package,
or, if, absent, package directive with synthetic package should be added.
2) in .kt files, import directives and fully-qualified import from interop modules
should be prepended with same test-specific synthetic package.
This test had the IGNORE_FIR2IR_EXCEPTIONS_IF_FIR_CONTAINS_ERRORS
directive enabled. This prevented some diagnostics from showing up
in this test, because there was this exception thrown in FIR2IR:
java.lang.IllegalStateException: IrSimpleFunctionPublicSymbolImpl for
/foo|foo(){}[0] is already bound:
FUN name:foo visibility:public modality:FINAL <> () returnType:kotlin.Unit
a0ba878b1d disabled the
`linkViaSignatures` flag in JS tests, which also fixed the exception.
Because of that, the full pipeline could be run, and the diagnostics
started to appear, which is the correct behavior.
Not that this only concerns _tests_, not production code, because
in the production pipeline `linkViaSignatures` had been disabled even
before that change.
This reverts commit 96b2f13397.
Unfortunately, in K2, the feature works only in JVM. KT-56466 The
feature is postponed till 2.2 (preview is postponed till 2.1)
KT-1436
There was a part of `FirNativeObjCNameChecker` which worked only with
callable declarations, so it makes sense to extract it into the separate
callable declarations-only checker. Also this separation will be useful
in the future changes, when this checkers will be implemented differently
for expect and non-expect classes in scope of KT-58881
Previously there were cross-references between `FirNativeObjCNameChecker`
and `FirNativeObjCNameOverridesChecker` checkers, which made the flow
of code quite non-intuitive
This commit extracts common methods and classes used by them into separate
`FirNativeObjCNameUtilities` object
While reporting a diagnostic there seems to be correct because the
parameter type is ConeErrorType, the former fact is a bug
in PCLA that should be fixed soon
Previously, error types on those implicit parameters were being lost.
Changed test data is only partly here
(only parts that are considered to be correct).
Other ones (new green-to-red changes) should belong to the next commit
and will be fixed soon (as a part of PCLA).
- use `FirImplicitInvokeCall` instance check to detect implicit calls,
it is cleaner than checking particular resolve type and "invoke" name
- reuse `visitQualifiedAccesses` to update the CFG instead of manually
searching through the `localProperties` (because it didn't work in the
case of overloads)
^KT-64832 Fixed
^KT-61032 Fixed
Sergej Jaskiewicz