IrCapturedType (which is a IrSimpleType) does not have variance, so it
is confusing to have it in IrSimpleTypeBuilder, and it's clearer to
construct type projection separately anyway.
- use identity in equals/hashCode. It was already effectively working
like this because of `constructor === other.constructor`
- implement variance and declare it in IrSimpleType
- remove obsolete TODO
- simplify code in captureFromArguments
- use data objects
IrStatementOriginImpl and IrDeclarationOriginImpl were made final
classes to simplify the creation of them (a delegate provider was
added) and to optimize performance when comparing the origins by type
and name
A full mangled name of a declaration is a mangled name that includes
the mangled names of all the declaration's parents.
We don't use full mangled names for building `IdSignature`s. We use them
in two places:
- Generating stable names for JavaScript functions in Kotlin/JS
(see `NameTables.kt`)
- Generating names for LLVM symbols from lowered IR functions in
Kotlin/Native (see `BinaryInterface.kt`)
In both of these places we run the IR mangler, hence we don't need this
functionality in other manglers.
Ideally, instead of this method, there should be a link
to IrModuleFragment. Unfortunately, it would require to big refactoring,
as some of IrPackageFragment implementations doesn't have any
IrModuleFragment inside, and are not located inside any
IrModuleFragment.
So for now, we just implement and use everywhere a single way of
getting the module descriptor, which respects a IrModuleFragment
link if it exists, and fallbacks to descriptor-based method
if it doesn't.
^KT-62623
This flag will be used on JVM to determine whether or not to generate
external enum entries mappings ("$EntriesMappings") classes. Note that
from the frontend's point of view, every enum has `entries`, so for
backend purposes we have to reach out to the underlying deserialized
data to read the flag from the metadata.
Review: https://jetbrains.team/p/kt/reviews/12279/files
Motivation: make sure that cases like KT-62027 won't happen again
Review: https://jetbrains.team/p/kt/reviews/12279/files
Now it's responsibility of the
`createExpectActualTypeParameterSubstitutor` calller to think about the
case when parameters size isn't equal. You must not be able to create a
substitutor if type parameters sizes are not equal
Improvement in `createExpectActualTypeParameterSubstitutor` API also
improves
`AbstractExpectActualCompatibilityChecker.getCallablesCompatibility`
API.
Because suppose that you accidentally created a redundant wrapping
substitutor => you need to handle the case of not equal type parameters
size on the call site => you start thinking why you should do that on
the call site? It must be a responsibility of
`getCallablesCompatibility` => you realize that you created a redundant
wrapping substitutor
It has been renamed to IdSignatureFactory. We have to keep
IdSignatureSerializer as a typealias for a while to keep the source
compatibility with the Compose compiler plugin.
Now there is separate class encapsulating logic about how to build
fakeOverrides and one encapsulating logic of which classes
do need building fake overrides.
This also allows to untie strange inheritance dependencies.
^KT-61934
Previously, it had some internal state that was saved between calls
and needed to be cleared.
This state was eliminated, which makes invariants clearer and using
easier.
^KT-61934
`FakeOverrideBuilder.provideFakeOverrides` recursively changes overrides
for all superclasses in the hierarchy, including lazy IR, which is a lot
of extra work.
Also it leads to some tests failing in the IR fake override builder mode
because it changes correct fake overrides of Java classes to incorrect
ones. Those tests are unmuted but it doesn't mean they are fixed -- most
likely we'll generate fake overrides via IR for lazy IR too, at which
point they'll start to fail again.
The header klib is supposed to only contain the public abi of the module
similar to jvm-abi-gen. It is intended to be used as a dependency for other
klib compilations instead of the full klib for compilation avoidance.
^KT-60807
`ManglerChecker` is a class that verifies that for each IR declaration
(except some, see its `needsChecking` property) its mangled name
(computed from IR) is the same as the mangled name computed from its
frontend representation — `DeclarationDescriptor` on K1 or
`FirDeclaration` on K2.
The way it does it is as follows.
On K1, `ManglerChecker` looks if the declaration has a true,
non-IR-based descriptor, it if it does, then it checks it
(see ManglerChecker.Companion#hasDescriptor).
On K2, since we don’t have any descriptors, `ManglerChecker` looks if
the declaration’s metadata property is `null` (because the corresponding
`FirDeclaration` is stored there). If it’s not, it checks it
(see ManglerChecker.Companion#hasMetadata).
The issue is that those two conditions are not equivalent.
When the Compose compiler plugin transforms an IR function, it copies
its `metadata` property (as it should, because `metadata` can contain
anything, not necessarily the frontend representation), but doesn't set
the descriptor. Because of that, on K1 that transformed function is
skipped in `ManglerChecker`, and on K2 it’s not.
The correct usage would be to properly distinguish which declarations
come from the FE as is, and which are transformed/synthesized,
and skip the latter. But it is unclear how to implement this.
For now, the easiest way to fix this on K2 is to not run ManglerChecker
at all.
KT-60648
^KT-59448 Fixed
Ensure that in IdSignatureBuilder hashId/hashIdAcc is only set
together with the description.
In 6142d75bb4 we implemented setting
descriptions when building signatures from descriptors, but forgot to
do the same for building signatures from IR, resulting in missing
descriptions in klibs.
See also: KT-59486
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)
Igor Chevdar