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
See the `privateInFile.fir.kt` test.
Type mismatches are simply confusing.
`inheritorOfExpectSealedClass.out`
reports unresolved reference probably
because now it resolves into the expect
declaration, rather than the actual one.
K1 doesn't report UNRESOLVED_REFERENCE
in this case. But this is red code
anyway. And this behavior still
depends on the order in which the compiler
receives both the declarations.
^KT-59927
^KT-62567
We only see the redeclaration
diagnostics on the declarations inside
the second file, because of
`FirRecorder::visitRegularClass`.
`data.state.classifierContainerFileMap`
references the last file, so
when checking the visibility of
the first `private class C { ... }`
(when collecting declarations that
conflict with the second `private class C`)
the provider returns the second file
instead of the first one, so the class
behaves as it is visible, and
`collectTopLevelConflict` returns in
this case.
As for why `INVISIBLE_*`s are reported
inside the first file: this is because
`data.state.classifierMap` stores the
last classifier it sees instead of
the first one.
^KT-62537
Access to `SLRUCache` is a bottleneck when we call `getLineNumber`.
We are very rarely going to access the same offset. This change
speeds up backend by approximately 0.43%.
Ilya Goncharov