Since nullability-flexible types in IR are represented by an annotation
on an IrSimpleType, not a special instance, the common implementation of
`KotlinTypeMarker.isMarkedNullable` in `TypeSystemContext` doesn't work.
This method is used for example to generate `typeOf` in JVM IR, in
`TypeSystemCommonBackendContext.generateTypeOf`, and this issue led to a
difference in behavior of `typeOf` for nullability-flexible types.
#KT-44726 Fixed
There was a problem with delegated extension property with dispatch
receiver that `this` in `getValue` call was set to dispatch receiver
instead of extension one
[JS IR] Add option for dce mode
[JS IR] Add logging to non useful declarations if appropriate dce mode
[JS IR] Add mode with throwing exception
[JS IR] unreachableDeclaration method is in rootDeclarations
[JS IR] Add js extra help arg with dce mode and include debug.kt to compile unreachableMethod
[JS IR] unreachableDeclaration as internal to not reproduce stdlib api
[JS IR] Fix description of dce mode argument
- Use console.error instead of console.log
- Use JsError instead Kotlin exception for lightweight
[JS IR] Remove body for throwing exception
[JS IR] Remove default parameter in unreachableDeclaration
[JS IR] Process without removing fields and declaration containers
[JS IR] Rename dce mode on dce runtime diagnostic
[JS IR] Use console.trace instead of console.error
[JS IR] Extract JsError
- Fix naming in prependFunctionCall
- Fix description on runtime diagnostic argument
- Using message collector instead of throwing exception
[JS IR] Distinguish unreachableMethods for log and exception
[JS IR] Extract checking of Kotlin packages of IrField
^KT-45059 fixed
Avoid generating synthetic overrides in subclass
It has been already working for PSI2IR because fake overrides there don't
inherit default values for parameters, while they do it in FIR
The difference is how we deal with intermediate fake overrides
E.g., in case
interface A { /* $1 */ fun foo() }
interface B : A {
/* $2 */ fake_override fun foo()
}
interface C : B {
/* $3 */ override fun foo()
}
We've got FIR declarations only for $1 and $3, but we've got
a fake override for $2 in IR.
Previously, override $3 had $1 as its overridden IR symbol, just because
FIR declaration of $3 doesn't know anything about $2.
Now, when generating IR for $2, we save the necessary information
and using it for $3, so it has $2 as overridden.
So, it's consistent with the overridden structure of FE 1.0 and this
structure is necessary prerequisite for proper building of bridges
for special built-ins.
Some of the changed data is correct, but some diagnostics are incorrect
Corner cases like having both contains(Object) and contains(String)
within implementation of Collection<String> is not supported
Alexander Udalov