make write protection directly in properties
it creates no additional wrapper with the link to the containing class
for ij project, this reduces memory usage for ~15 mb
^KT-56351
We can use less strict rule for produced annotations:
* Previously: the same annotations from `findAnnotation` and `annotations`
have the same identity
* Now: the same annotations from `findAnnotation` and `annotations`
are equals by 'equals'
^KT-56046
- Also, this error allows IDE to provide quick-fix that changes language
version in a project that simplifies the adoption
- There is no point in
changing K2 part as there this feature will be enabled by default
^KT-56224 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.
Dmitrii Gridin