We always set the $assertionsDisabled field based on the top-level
enclosing class. This means that for anonymous objects we have to
rewrite the call to Class.desiredAssertionStatus.
values within initializer blocks.
The issue occurs in code like this:
```
class C {
var b = true
init {
b = false // Missing PUTFIELD for this statement
}
}
```
Added a new statement origin for field initialization (at declaration)
instead of relying on `origin == null` in ExpressionCodegen to determine
whether to generate the initializations.
This was unintentionally broken in
d68a1898d0.
If a part of an 'if' condition is an inline function call, we need to insert the original condition line after it. Otherwise, the debugger will think it is inside the inline function implementation. Obviously, this breaks stepping – instead of the 'if' body, we go on stepping through the inline function.
This commit fixes 'KotlinSteppingTestGenerated.StepOver#testSoInlineLibFun' test.
This commit fixes the following tests:
- KotlinSteppingTestGenerated.StepOver#testSoInlineLibFun
- KotlinSteppingTestGenerated.StepOver#testSoInlineIterableFun
- KotlinSteppingTestGenerated.StepOver#testSoInlineFunOnOneLineFor
- Uncomment tests
- Add proper visibility to companion field
+ Make exception for interfaces -> they need to respect language versions 1.8
before they can put private members there.
- Adjust synthetic accessor lowering to look for enclosing classes with access
via companion object.
backends by removing IMPLICIT_NOTNULL casts from IrStringConcatenation
arguments.
Also fixed an issue where IrStringConcatenation can be lowered into
a null String instead of a literal "null" String if the lone argument
was a platform type String or String with enhanced nullability and the
value was null (e.g., "${FromJava.nullPlatformString()}").
Don't insert implicit null check on a value of @EnhancedNullability type
used where @EnhancedNullability type is expected.
This uncovers a bunch of other problems in FE and BE.
KT-36343 and KT-36347 are bugs in StrictJavaNullabilityAssertions
implementation which should most likely be fixed in next major language
version (with proper breaking change notice).
KT-36344 is a design problem which should be addressed after 1.4 issues
are resolved.
Final default properties accessors that access a backing field
on the same class can be replaced by direct field use.
Perform the optimization late in the pipeline to allow lowerings
to expose more opportunities for optimizations.
Final default properties accessors that access a backing field
on the same class can be replaced by direct field use.
Perform the optimization late in the pipeline to allow lowerings
to expose more opportunities for optimizations.
Do not check for occurrences of "this" on the current backend.
I accidentally unified the checking for the two backends
without checking that it worked (used the wrong test suite to
test).
The first change here is swapping the isCompatibility and hasJvmDefault
checks. Otherwise behavior could be different depending on -Xjvm-default
mode even for non-JvmDefault declarations, which makes little sense.
Another change is avoiding generating $default stubs for fake overrides
in interfaces, which replicates the behavior of the current backend.
(Note that this change also fixes the first problem on the newly added
tests, but the first change seems useful anyway.)
Alternatively, we could improve the lookup utilities and their usages to
always find the exact override of a symbol from
Collection/Iterable/CharSequence/etc, but since we need to load the
original symbol anyway in cases when the loop subject's type is a type
parameter, we might as well simplify everything and always reference the
original symbol.
Also improve exception message and removed unused declarations in
IrBackendUtils.kt.
This corresponds to the ABI generated by the old backend. Moreover, when
compiling the module 'ir.tree' with JVM IR (could not reproduce on a
small sample), this led to a codegen crash when trying to reassign
parameter value to the default stub, which is an error expression and
can't be generated by ExpressionCodegen.
- introduce a scoped counter instead of a global one for name
generation for accessors. Naive solution not working.
- Introduced hardcoded "jd" suffix for accessors on interfaces, under
the assumption that the only such accessors are due to JvmDefault
and their bridges from `$DefaultImpls`. Removed all associated
templated tests, so the old and IR backend correspond on this matter
again.
- Respecialized writeFlags from regexps to string-equality: we are
going for exact matches now!
- Fixed package calculation in `IrUtils.kt`.
- Accessors for static members must be due to accessing super
classes. Actual super-qualified calls are naturally also accessing
super classes. Hence the `$s+{hashcode(superClassName)}`
suffix. Added test to affirm this naming scheme.
- Field getters/setters for static fields must be companion accessors,
otherwise just labelled as accessors. They are also tagged with `s`
suffix when accessing static fields.
- For naming of accessors to coincide with the old backend, field
renaming to avoid JVM signature clashes must be done _after_
generation of accessors for those fields.
Change the treatment of default implementations on interfaces in JVM
compatibility mode. Previously, the IR backend moved the actual
default implementation to the DefaultImpls class, and then bridged to
it from the interface default. The old backend did the reverse, at the
cost of an additional accessor, in order to gain better binary
compatibility properties. See #2612 for discussion.
The accessor needs to call a specific implementation, so must be
performed through an `invokespecial`. We trick the
SyntheticAccessorLowering into doing this for us, by marking the
bridging call as a super call. We do this in want of an explicit
`invokespecial` Ir Node.
InterfaceDefaultCallsPhase previously assumed the old behaviour of the
IR backend (that calls to default implementations, e.g. `foo$default`
should target `DefaultImpls.foo$default`). But now the bridge to
foo$default resides on `DefaultImpls` already, causing that pass to
create a recursive loop. We cut that loop with a simple check.
