Intersections for interfaces and generic interfaces work differently.
`FirIntersectionCallableSymbol.getNonSubsumedOverriddenSymbols()`
does not retrieve the original symbol for a symbol inherited from
generic interfaces.
The patch explicitly obtains original symbols if they exist.
^KT-65216 Fixed
This fixes a bunch of missing overridden symbols in IR.
This is also required for fixing KT-59921 in the following commit
where we need to keep all overridden symbols of intersection overrides
so that we can enhance them properly.
#KT-57300 Fixed
#KT-57299 Fixed
#KT-59921
#KT-57300
#KT-62788
#KT-64271
#KT-64382
FirConstExpression is usually confused with "constant" calculations,
while in fact, it just denotes a simple literal expression
and `1 + 1` isn't represented by a FirConstExpression.
^KT-64314 Fixed
`FirDeserializedEnumAccessExpression` requires session to build proper
reference, so it's important to have it in all utilities, which may
pass this element as input
^KT-64975
There are some cases when we want to run some platform checker not from
platform session but from common session. All such cases appear when
we check some `expect` class
```kotlin
// MODULE: common
expect interface A
expect class B : A
class C : A
// MODULE: platform()()(common)
actual interface A {
fun foo()
}
actual class B : A {
override fun foo() {}
}
```
In this example we want to report "abstract foo not implemented" on
class `C`, but we don't want to report it on `expect class B` (as
its supertype is always `expect A`, never `actual A`)
So to cover such cases some platform checkers were split into two parts:
- `Regular`, which is platform checkers and runs for everything except
expect declaration
- `ForExpectClass`, which is common checkers and runs only for expect
declarations
^KT-58881 Fixed
^KT-58881 Fixed
^KT-64187 Fixed
This commit introduces MppChecker kind, which represents the new property
of checkers
- `MppCheckerKind.Common` means that this checker should run from the same
session to which corresponding declaration belongs
- `MppCheckerKind.Platform` means that in case of MPP compilation this
checker should run with session of leaf platform module for sources
of all modules
An example of a platform checker is a checker that checks class scopes
and reports ABSTRACT_NOT_IMPLEMENTED and similar diagnostics. If some
regular class in the common module contains expect supertypes, the
checker should consider the actualization of those supertypes to get
a complete type scope
^KT-58881
- Fix a false positive JS_NAME_CLASH report on constructors
from different classes but with the same JsName.
- Allow the same JsName for class constructors and other top-level
declarations. This behavior differs from K1, but it is correct
since there is no real name clash in the generated JS code.
^KT-64867 Fixed
Otherwise, these tests fail due to
misplaced diagnostics in LT:
- `testExtensionFunctionArgumentOrReturnType`
- `testInlineClassAsParameterOrReturnType_allowed_kt`
- `testInlineClassAsParameterOrReturnType_kt`
StandardClassIds was using Annotations subclass in its initialization.
At the same time, Annotations subclass was using StandardClassIds in its
initialization implicitly through baseId() method.
This leads to a rare deadlock on CI in case where two different threads
tried to initialize both classes at the same time.
It can't be reproduced robustly, as a single thread was able to
successfully initialize both, and will do it on an attempt to
initialize any of them.
^KT-64720 Fixed
- use a declaration source if a parameter source is null;
- ignore constructor return type to avoid
double-checking of the class itself;
- ignore constructor type parameters
obtained from the class declaration;
- ignore enum entries property (it is not checked in K1 at all);
- fix exportability check for function types;
^KT-63089 Fixed
The meaning of this check is the same as K1
JSCODE_ARGUMENT_SHOULD_BE_CONSTANT and JSCODE_ARGUMENT_NON_CONST_EXPRESSION
diagnostics.
The main difference is that K2 JSCODE_ARGUMENT_NON_CONST_EXPRESSION
diagnostic checks the js() argument in the same way as
const val initializers or annotation arguments are checked.
This means that, the K2 diagnostic is stricter than original
K1 JSCODE_ARGUMENT_SHOULD_BE_CONSTANT diagnostic,
which allows the use of non-constant vals.
^KT-59435 Fixed
There's no module kind check for IDE at the moment: IDE modules don't
have access to compiler arguments or configuration. K1 currently doesn't
report the diagnostic either. See KTIJ-27279 for more details.
This commit repeats K1 behaviour: K2 IDE won't fail because of the
missing service, but the diagnostic won't be reported in IDE, only
during compilation.
KT-61615
Kirill Rakhman