This commit removes the default parameter in constructor,
as well as custom logic in this class, which would
make it harder for its subsequent auto-generation.
^KT-65773 In Progress
This problem is extensively described in
`cadbc87dfd1ce3e63481ab90874ca8858878c55f` commit message.
TLDR: compiler is also called from Android LiveEdit plugin where
we want to be able to use compiler plugins. For that reason, we have two
different flags in the compiler. One is only for "evaluate expression"
(`doNotLoadDependencyModuleHeaders`) and the other for both LiveEdit
plugin and "evaluate expression" (`shouldStubAndNotLinkUnboundSymbols)`.
We want to forbid using compiler extensions for "evaluate expression"
and allow for LiveEdit plugin.
#KT-63695
This is an extended version of the fix in
57d912a5d4. We don't want to use any
plugins in code fragment compilation, but we still get them through
`project` because they are registered in IDEA. So we just fully
exclude `irPluginContext`.
#KT-63695 Fixed
When compiling code fragment, we forbid to use `irLinker` as
IR provider. Because of that, if there are some plugin
extensions, we will not be able to find deserializer
for a given module and will fail.
#KT-63695 Fixed
This is an addition to d16f33cf5b. Apparently there's another call site
of JvmIrCodegenFactory in intellij besides Evaluate Expression, namely
Android LiveEdit plugin, where it seems needed to collect all dependency
modules and resolve them via linker. LiveEdit also uses
shouldStubAndNotLinkUnboundSymbols = true, so we need to differentiate
between it and Evaluate Expression, hence the new flag. This new flag
will be set to true only for Evaluate Expression in intellij.
#IDEA-329915
Collecting all modules takes a lot of time in Evaluate Expression in
IDE, and it's useless because we then invoke JvmIrLinker to load module
headers, but that linker is discarded in the IDE (see `val irProviders`
below).
#IDEA-329915
This is needed for two reasons:
1. Consistency
2. It should run after compiler plugins, which are now runs after fir2ir
is finished for all modules
^KT-56173
- When the bytecode tool window opens a file containing `actual`
declarations, not all the `expect` symbols reachable via the `actual`
symbols' descriptors might be contained in the symbol table, because
the source of the `expect` members is not included in the files to
compile. This caused an issue during lowering in
`ExpectDeclarationRemover.tryCopyDefaultArguments`.
- The solution adds `expect` symbols reachable via `actual` declarations
to the symbol table, so that these `expect` symbols can subsequently
be stubbed.
^KTIJ-25152 fixed
1. Leaving no unbound symbols in the IR tree, KT-54491:
- All unbound symbols are bound to synthetic stub declarations
- Improved detection of the root cause for every partially linked classifier
- Improved error messages
2. Visibility valiation, KT-54469
3. Always check deserialized symbols:
If the deserialized symbol mismatches the symbol kind at the call site in the deserializer then generate and reference another symbol with the same signature. In case PL is off, just throw IrSymbolTypeMismatchException.
4. Handle class inheritance violation:
- Detect illegal inheritance (ex: inheriting from a final class)
- Detect invalid constructor delegation (ex: delegating to another class than the direct superclass)
- Simplification: Reduce the number of PartialLinkageCase subclasses
- Reworked error message generation to have shorter and clearer messages
5. Handle class transformations and all known side-effects, examples:
- nested <-> inner
- class <-> enum/object
- adding/removing subclasses of sealed class
- adding/removing enum entries
6. Check direct instantiation of abstract class.
Such instantiation could be possible if a class was non-abstract in the previous version of a library.
7. Handle unlinked annotations on declarations.
Such annotations are removed from the IR. The appropriate compiler error message is produced for every individual case.
8. Handle value argument count mismatch at call sites
9. Handle calling suspend function from non-suspend context.
This could happen if a suspen function was non-suspend in the previous version of a library.
10. Handle overriding inline callables.
Only the leaf final callable can be marked with `inline`.
11. Detect illegal non-local returns from noinline/crossinline lambdas.
- 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
- 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
Because in kapt stub generation mode (aka ClassBuilderMode.KAPT3, aka
generateBodies=false in psi2ir), method bodies are not generated and
compiler plugins such as kotlinx-serialization might not expect that.
#KT-54245 Fixed
Basically, some package names were Native-specific, whilst the packages
themselves were not Native-specific at all. This was already reflected
in the directory layout, but not in the package names.
This is fixed here.
NFC, just an automatic rename of packages with fixes of imports.
Currently, compiler pipelines are heavily couples with
NamedCompilerPhase. Unfortunately, NamedCompilerPhase uses the same
type for Input and Output, thus it is not applicable to phases that
try to transform some data purely.
Thus, we separate this class into two, allowing to have a new
inheritor of NamedCompilerPhase with different Input and Output types.
Disable it if we do not have required `noCompiledSerializer` function in
runtime. Leave it enabled in tests.
Rollback some changes for old backend as it is unsupported now.
Add intrinsic for kotlinx.serialization.serializer<T>() function.
Plugin intrinsic for old backend is removed because it is too hard
and unjustifiable to unify them.
... and the corresponding type parameter has a non-trivial (i.e.
non-`Any?`) upper bound.
The best solution here would be to get rid of
`removeExternalProjections` completely, and just use the type of the
argument at the call site, but see KT-52428.
#KT-51868 Fixed
Wojciech Litewka