The thing is, in a box test there is a proper
`UNRESOLVED_REFERENCE` on `M2().a.m2()` in K1 as well,
but it's not present in diagnostic tests. And also,
there's no error in the Kotlin IntelliJ plugin when
viewing such code.
It looks dangerous, but since this code is about
classes with identical fqNames, and since nothing
sus is really compiled, we can probably ignore this
problem. It's unlikely that it impacts much.
`invoke()` function of functional types is always defined
in such a way that its explicit receiver comes as the first
value parameter. Extension-function types contain the very
same `invoke` function, they just additionally have the
`@ExtensionFunctionType` annotation.
In the related test there is such an `invoke` function and
in the presented call its explicit receiver is the anonymous
function `fun Int.() = 1` itself. So the safe-checked `1`
^KT-60056
Replace every property with its getter and setter. This is needed
because later on, JVM backend assumes that all properties have been
lowered (by JvmPropertiesLowering) to this state.
#KT-64116 Fixed
While not beeing final solution, this is closer to what
we want to have in the end. Enabling on non-JVM targets
would help better testing.
Enabling in JVM is now not possible yet, as some of the bugs are
not fixed yet (check KT-61360 for details)
^KT-62476
Because of KT-64743 there is unexpanded type-alias in a place we don't
expect it to occur. To workaround this, we just expand typialiases in
one more place.
^KT-64743
We shouldn't build expect declarations as they do not
exist. We can omit check on member declarations as we
won't request them as we skip expect classes
^KT-57536 Fixed
Multifile-class can contain not only files from the same
module, but also files from the common part.
This commit also fixes KotlinByModulesResolutionScopeProvider as
it should provide all transitive dependencies
^KT-64714 Fixed
To call retrieveDirectOverriddenOf,
one must use directly the owner scope of a callable symbol we consider,
and not a scope of some derived class.
#KT-64276 Fixed
Make sure SENSELESS_COMPARISON
is absent in this case.
^KT-64089 Obsolete
Merge-request: KT-MR-13754
Merged-by: Nikolay Lunyak <Nikolay.Lunyak@jetbrains.com>
It started failing because of other
changes having been merged right before it
^KT-64644 Fixed
Merge-request: KT-MR-13755
Merged-by: Nikolay Lunyak <Nikolay.Lunyak@jetbrains.com>
Java resolving subsystem requires calculated visibility for correct disambiguation of supertypes.
But visibility remains `Unknown` for Kotlin class-like declarations during supertypes resolving because `STATUS` resolve phase is performed after `SUPER_TYPES` phase.
To fix the problem, the visibility should be initialized to public at the FIR building phase if no modifier is presented.
^KT-64127 Fixed
We don't have true flexible types in the IR, but we approximate it with
internal type annotations, such as FlexibleNullability,
FlexibleMutability, RawType. These annotations are then handled
specially in JvmIrTypeSystemContext, which can construct a fake flexible
type so that type checker on IR types would behave exactly as on
frontend types.
As shown in KT-63441, one instance of flexible types where flexibility
was lost during conversion to IR is Java array/vararg types. It's
necessary to support it so that IR fake overrides could be constructed
correctly, because IR fake override checker requires parameter types to
be equal. So this change introduces another internal type annotation,
FlexibleArrayElementVariance, which is only applicable to types with
classifier kotlin/Array, and which signifies that the annotated type
`Array<X>` should rather be seen as `Array<X>..Array<out X>`.
#KT-63441 Fixed
#KT-63446 Fixed
When performing lookahead for local variable assignments, make sure
assignments taking place within loops are being propagated before loops.
This makes sure smartcasts within non-inline declarations before the
loop are disallowed.
^KT-63867 Fixed
Previously we just skipped Java sources.
The order of classes in light classes test data is changed due to
differences in implementations of `compileLibraryToJar` and `runJvmCompiler`
^KT-62892
This diagnostic may be reported even without any compiler plugins (e.g.
for annotation named `Target` or `Deprecated`), so the old name
and message were quite confusing
^KT-64654
Nikolay Lunyak