Trick codegen into generating getfield from the anonymous class instead
of its supertype (e.g. kotlin.jvm.internal.FunctionReference,
PropertyReference or AdaptedFunctionReference). This gets rid of
unnecessary accessors in some cases, and will help in the subsequent
commit that changes logic around access to fields from Java
superclasses.
It was added in 66da676b9e to avoid dependency on descriptors, but now
it doesn't use descriptors anyway, so it's better to inline it than have
it in the interface.
The IR linker is responsible for detecting unbound symbols,
if it skips them for some reason, IC infrastructure must not fail
with unbound symbols exceptions. Anyway, the IR validator
verifies later if there are unbound symbols in
reachable IR and generates the corresponding error.
^KT-56602 Fixed
If a developer interrupts (kill gradle process) a compilation process or
an internal error interrupts the compilation process,
the incremental cache files may be corrupted.
The patch creates a special guard file, which allows detecting
if the previous compilation was not successful,
and in case of any issues drops the incremental cache files.
^KT-56581 Fixed
JS IR BE incremental compilation infrastructure uses
LanguageVersionSettings::toString method to detect if any
compiler features or flags were enabled or disabled.
It is important that the features and flags order are stable
in the result string.
^KT-56580 Fixed
- Add IrPluginContext to JvmBackendContext, so plugin intrinsics can
reference external functions properly.
- Do not use module.findClassAcrossModuleDependencies as Descriptor API does not work for FIR.
- Add asm listing tests in serialization plugin for K2
- Remove Delegated.kt asm listing test as we have similar test in boxIr group.
#KT-56553 Fixed
The dependency signature may refer to function type interface properties
(e.g. name) or methods. It is impossible to detect (without hacks)
which binary symbol for loading is required. However, when loading
a property or a method the entire function type interface is loaded.
And vice versa, a loading of function type interface loads
properties and methods as well. Therefore, load the top level signature only,
it must be the signature of function type interface.
^KT-56582 Fixed
* Fix objects in inline functions and lambdas:
* Add common lowerings used in K/JS and K/Native
* Fix inline lambda call detection logic in presence of additional casts
Merge-request: KT-MR-8791
Merged-by: Svyatoslav Kuzmich <svyatoslav.kuzmich@jetbrains.com>
This inconsistency is present due to not using the `// WITH_STDLIB`
in the above tests. When K1 creates the enum, it tries to generate
`entries()`, and for that it tries to load `kotlin.enums.EnumEntries`,
but this is actually an unresolved reference. K1 silently swallows it,
and proceeds.
The reason K2 doesn't fail is that in order to generate `entries()` it
simply creates the necessary `ConeClassLikeType` with the desired
`classId` instead of loading the whole `ClassDescriptor`.
The reason we can still observe `$ENTRIES` and `$entries` in K1
is because they are generated during the JVM codegen, and it
only checks if the `EnumEntries` language feature is supported. It
doesn't check if the `entries` property has really existed in IR
(by this time it's expected to have already been lowered to the
`get-entries` function - that's why "has ... existed").
The reason why the codegen doesn't fail when working with
`kotlin.enums.EnumEntries` is because it creates its
own `IrClassSymbol`.
^KT-55840 Fixed
Merge-request: KT-MR-8727
Merged-by: Nikolay Lunyak <Nikolay.Lunyak@jetbrains.com>
Source mapping URL is not saved in JS module cache anymore,
because it was a wrong url pointed to the source map from the cache.
Instead, the URL is appended every time on writing the output JS code.
^KT-56469 Fixed
Apparently it depended on the ordering of the synthetic `$annotations`
methods generated for properties. And those methods were always
generated at the end of a Java stub by kapt because they lacked PSI
element, and thus `ClassFileToSourceStubConverter.convertClass` could
not compute their source position, and it placed them at the end as all
other synthetic methods.
The solution is to provide PSI element for `$annotations` methods in
JvmDeclarationOrigin. This origin is then collected in kapt in
`OriginCollectingClassBuilderFactory` and used for sorting, as in the
case of the old JVM backend.
#KT-56360 Fixed
The patch removes logic of generating extra IrFiles (fake file) into
IrModuleFragment for the function type interfaces during klib deserialization,
because IC infrastructure can not process files which do not exist in klib.
Instead of adding extra IrFiles during deserialization, the empty files
with required packages are added into Kotlin/JS stdlib physically.
These files are used as containers for function type interface declarations.
Since Kotlin/WASM uses the same klib loading infrastructure as Kotlin/JS,
the the empty files are added into Kotlin/WASM stdlib as well.
The patch also adds a check that IrModuleFagment has files only from klib.
^KT-55720 Fixed
- Symbols without a descriptor (e.g. `IrClassPublicSymbolImpl`) were
causing exceptions in `DeclarationStubGenerator` after recent changes,
because their property `irClassSymbol.descriptor` doesn't necessarily
exist without the symbol having an owner bound to it first.
- `DeclarationStubGenerator` now falls back to its `descriptor` argument
if `irClassSymbol` doesn't have a descriptor.
- Built-in symbol deduplication has only been tested with stubbing
enabled. Because there is no current use case for deduplication
without stubbing, an exception will be thrown to communicate the
misconfiguration.
- Some built-in symbols like `OptIn` haven't been created yet by the
time `irBuiltIns` is bound to `SymbolTableWithBuiltInsDeduplication`.
This caused an issue where `DeclarationStubGenerator` would get the
built-in symbol from `referenceClass`, but still stub for the original
duplicate `descriptor` and its associated own symbol. Because
`generateClassStub` would check `referenceClass.isBound` for the
built-in symbol, `isBound` was never checked for the duplicate symbol
and thus a "symbol already bound" exception occurred if
`generateClassStub` was invoked twice for a duplicate `descriptor`.
- The solution takes the descriptor from the `IrClassSymbol` returned
by `referenceClass`.
- When the IR backend is invoked from the bytecode tool window,
multiple descriptors may exist of the same built-in. For example,
there may be multiple descriptors for `Boolean`.
- This caused issues when the `IrClassifierSymbol` of a type was used
as a key for some built-ins map (such as `primitiveRefProviders` in
`JvmSharedVariablesManager`). Because while the reference map is
built from predeclared built-ins, with duplicate descriptors,
multiple `IrClassifierSymbol`s may exist for the same type. Such a
duplicated symbol would lead to an exception.
- The solution invents a special symbol table which de-duplicates
built-ins at the point where `IrClassSymbol`s are created.
I tried other approaches:
- It's possible to fix the symptoms in `JvmSharedVariablesManager` and
`JvmSymbols` by turning the keys of the requisite maps, i.e.
`primitiveRefProviders` and `arraysCopyOfFunctions`, from
`IrClassifierSymbol` to something like a `Name` or `PrimitiveType`.
This however touches the IR backend beyond the IDE and still leaves
error potential for all the other possibly duplicated built-ins.
- I tried to handle built-ins in `DeclarationStubGenerator` specially,
to circumvent the issue of duplicated descriptors, but this is not a
solution because the duplicated `IrClassSymbol`s will already be part
of the IR at that point.
^KTIJ-24335 fixed
- Property getters and setters are not marked as `isExpect` even if the
corresponding property is. This commit fixes the generation of actual
stubs for such functions.
- The cause for KTIJ-24206 is that the `expect` function's parent is an
`IrFile` instead of an `IrClass`. This is because
`ExpectDeclarationsRemoveLowering` removes `expect` declarations
before `FileClassLowering` can replace `IrFile` parents.
- That behavior is normally okay, but breaks down when an `expect`
declaration has no associated `actual` declaration. In such cases,
`ExpectDeclarationsRemoveLowering` doesn't replace `expect` symbols in
expressions with their corresponding `actual` symbols, as it normally
would.
- The solution fills in `ExpectDeclarationsRemoveLowering`'s behavior
by replacing `expect` symbols for which no `actual` symbols exist with
stubs. See `stubOrphanedExpectSymbols`.
- To not mess with the lowerings, `stubOrphanedExpectSymbols` is invoked
during IR generation. It uses the same `ExpectSymbolTransformer`
as `ExpectDeclarationRemover`.
^KTIJ-24206 fixed
It is difficult to implement properly tail calls for a real coroutine (when there
are other non tail calls), because of continuation interception semantics. And the
benefits aren't clear at this point, so let's turn it off for now.
Remove code generation for external fake overrides
Fake overrides are resolved to real declaration on call sites
This also removes generation of unused
"equals", "hashCode" and "toString" methods.
Avoid using hashes of IrType in generated code
because they are unstable
Merge-request: KT-MR-8658
Merged-by: Svyatoslav Kuzmich <svyatoslav.kuzmich@jetbrains.com>
These type parameters where used in function parameters,
but since suspendImpl is static function, it has no access
to class type parameters. Solution is to copy them to
the function itself.
#KT-55125 Fixed
Review: https://jetbrains.team/p/kt/reviews/8401
- Drop unused variables
- Replace `assert` with `require` because `assert` isn't reliable which
makes hard to do any judgements about the code (`-ea` flag must be
passed to the VM for the `assert` to be active. And it's hard to know
when we the flag is passed). If `assert` was here for the performance
reasons then a comment should have been left.
- Add the assert message for clearity
Because I'm evaluating what will break if KotlinAbiVersion is bumped.
And when the code around KotlinAbiVersion is clean it's easier to do the
evaluation.
Ilmir Usmanov