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.
The reason for switching from lazyWrapper to SymbolTable itself is that
(at least in JS_IR) some of those lazily created structures could later
be deserialized, which created conflicts.
We cannot be sure that we won't change behavior of these functions in
some corner cases, so only perform this optimization if the API version
specified by the user is not greater than the compiler's own stdlib
version it was compiled against. This is the same as the similar code in
the old backend in IntrinsicMethods.
Had to edit some bytecodeText tests to account for the fact that JVM_IR
no longer generates explicit initializations for ConstantValue fields,
but NoConstantValueAttributeForNonConstVals is not the default yet.
The goal was to be able to use such symbols before BackendContext is even created – in psi2ir postprocessing step (i.e., IR compiler plugins).
Remove old code from serialization ir plugin.
LazyIR was emitted because plugin was not able to declare symbols, only to reference them.
Moreover, declarations added by frontend plugin were also unbound symbols produced by psi2ir,
and declaration stub generator was stubbing them with LazyIR – therefore access to global symbol table is not enough for plugins. IrProvider won't help here, because some functions produced by plugin have circular dependencies.
By moving compiler plugins step between psi2ir and declaration stub generator, both problems are resolved
– unbound symbols produced by psi2ir and compiler plugins are declared where they would be declared if this was a user code,
and only unbound symbols left are external dependencies, which is a correct input for lazy ir.
Replaced createTemporaryVariable usages with createTmpVariables.
The latter doesn't rely on KotlinType's. Using KotlinType with
JS_IR backend causes runtime excpetions, as some expected descriptor
API is not implemented, because it avoids descriptors as much as
possible.
* When referencing the companion itself, they should use the $$INSTANCE
field, not the (null until <clinit> returns) Companion field of the
interface.
* Interface companion init blocks should be made static.
- don't box/unbox when value is known to be an inline class
- add unbox state when coroutine resumed
- correctly handle suspension in case of inline class
- add tests
- fix BE
- fix Serializer
- implement builder
- make Ir a bit more type-correct
- support developer mode (lowering [dynamic]implicit cast meterialized as general cast)
- fix autoboxing lowering
The ir type checker cannot deal with types with an incorrect number of arguments.
On the other hand, the JVM IR backend sometimes produces "raw types" - types with
generic parameters but without arguments. This commit removes such raw types as
much as possible, by replacing calls to "typeWith()" with calls to "defaultType"
for classes without type parametes (defaultType doesn't allocate, unlike typeWith)
and with calls to "starProjectedType" for classes with type parameters.
The check for whether a function needs a default stub should run fewer
times now, and in particular is no longer quadratic. Also, this fixes
a weirdness in that certain inheritance hierarchies would produce
a default stub that points to a non-stub through its overriddenSymbols
field.
Otherwise a local class in a field initializer or anonymous init block
is copied into each constructor of the containing class (because
InitializersLowering calls deepCopy).
Since the code structure no longer resembles the original source code
here, record a custom EnclosingMethod mapping before moving such
classes, and use it in codegen.
Georgy Bronnikov