Other type substitutors (classic, cone-based) respect the type
annotations and copy them to the resulting type for all
cases, including type parameters.
Without this change we cannot correctly match expect/actuals
when we replace actual type parameters with expect ones in case
the actual type parameter has type enhancement annotations
(e.g., `@FlexibleNullability`).
We transfer all annotations (and not conservatively copy only type
enhancement annotations), as 1) other substitutors do that 2) other
IR type substitution utilities (e.g., `IrType.substitute`) do that.
As we will attempt reimplementing all IR type substitution utilities
via IrTypeSubstitutor, it also makes sense to completely align
the behavior.
The following updates in the JVM/IR plugin were made:
* Lots of refactoring with preparation for K/N support: commonization of transformations.
* Improved error handling (checks for visibility constraints, appending message about usage constraints in case of an error).
* Explicit requirements for the visibility of atomic properties: to prevent leaking they should be private/internal or be members of private/internal classes.
* Fixed visibility of generated properties: volatile properties are always private and atomic updaters have the same visibility as the original atomic property.
* Volatile fields are generated from scratch and original atomic properties are removed.
* Delegated properties support is fixed (only declaration in the same scope is allowed).
* Non-inline atomic extensions are forbidden.
* For top-level atomics: only one wrapper class per file (with corresponding visibility) is generated.
* Bug fixes.
The corresponding tickets:
https://github.com/Kotlin/kotlinx-atomicfu/issues/322
KT-60528
Merge-request: KT-MR-10579
Merged-by: Maria Sokolova <maria.sokolova@jetbrains.com>
After this change SymbolTable (and ReferenceSymbolTable) contains only
methods with IdSignatures. All descriptors-related methods are moved
into DescriptorSymbolTableExtension, which automatically delegates to
the SymbolTable if needed
At this moment there are cross-references between SymbolTable, because
descriptor API is still actively used across backends. So SymbolTable
is accessible in some place then descriptor extension will be accessible
too
DescriptorSymbolTableExtension is an implementation of abstract SymbolTableExtension
which allows to implement different kinds of storages, e.g. FIR based
(it probably will be needed for FIR2IR)
This will help in some lowerings which need to change the callee of a
call. Instead of creating a new call and copying everything (type
arguments, value arguments, receivers, annotations, attributes, ...),
it's easier to modify the `symbol`. In a way, this is a continuation of
22b4b29292.
This field shall be used for storing a human-readable representation
of the declaration, that would be a mangled name for now.
This field is not yet serialized. Serialization will be implemented in
follow-up commits.
See KT-59486
marat.akhin