FirConstExpression is usually confused with "constant" calculations,
while in fact, it just denotes a simple literal expression
and `1 + 1` isn't represented by a FirConstExpression.
^KT-64314 Fixed
`FirDeserializedEnumAccessExpression` requires session to build proper
reference, so it's important to have it in all utilities, which may
pass this element as input
^KT-64975
3aa84906 changed native metadata serialization to use proper platform
session, but it caused a new bug: FirKLibSerializerExtension uses
FirProvider from the passed session to get a containing file of
serialized declaration to put some extension into the metadata. And
platform session doesn't contain information about any declarations
except platform ones
So it's needed to use the proper FirProvider in it, which can be
extracted from Fir2IrComponents. This provider contains providers from
all sessions that are being compiled plus providers for top-level
declarations generated by compiler plugins
^KT-65024 Fixed
^KT-64121 Fixed
Review: https://jetbrains.team/p/kt/reviews/13495/timeline
If we generate these declarations then the compiler sees Any.{toString,
equals, hashCode} non-synthetic declarations of common metadata and
reports false positive ACTUAL_MISSING during intermediate (HMPP)
metadata compilation.
See the review for more details
It's now impossible to add new classes to metadata, because this
functionality is not implemented in IrGeneratedDeclarationsRegistrar
and FirDeclarationsForMetadataProviderExtension is removed
This leads to type ref referring to generic type variables being
serialized correctly.
When the type variable is declared on the member itself, it's written to
typeParameterName,
otherwise it's written to typeParameter. This is required for
deserialization to work correctly.
#KT-63227 Fixed
#KT-62305 fixed
NB: kotlin reflection do not see script class constructor after
this change, and it's ok, since the fact that the script is compiled
into a class is an implementation detail.
If needed, java reflection could be used to access the constructor.
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
Previous attempt was at 6807ed6642, but it was reverted in 7771e5914d
(see that commit for the explanation). Now it should be fine to remove
these version requirements.
No issue reported because it's mostly not a user-visible change. The
main effect is that it reduces differences in metadata between K1 and
K2, namely it fixes the ValueClass.kt kotlinp test.
K1 uses `Any?` in `transformSuspendFunctionToRuntimeFunctionType`, so
use `Any?` in K2 too.
This type is not used for anything, it's just an artifact of how suspend
types are represented in metadata. It's removed during deserialization
(see `TypeDeserializer.createSuspendFunctionType` or
`FirTypeDeserializer.createSuspendFunctionType`). So it's not a
user-visible change. The only effect is that it reduces differences in
metadata between K1 and K2, namely in the test
`libraries/tools/kotlinp/testData/ValueClass.kt`.
Language feature InlineClasses is enabled since 1.3. The current lowest
supported language version is 1.4, so any compiler that can read
binaries produced by the current compiler also supports inline classes,
which means that the version requirement is not needed anymore.
No issue reported because it's mostly not a user-visible change. The
main effect is that it reduces differences in metadata between K1 and
K2, because K2 never supported writing this version requirement properly
due to the TODO in `hasInlineClassTypesInSignature`.
This is needed to be able to precisely distinguish different synthetic
declarations (like fields for delegates and functions for data classes)
in fir2ir
When compatibleOnly == false, the logic was equivalent to returning
singleOrNull.
The only call-site with compatibleOnly = true was FirElementSerializer,
but after the fix for KT-59613, the map will never contain multiple
entries when one of the entries is compatible.
Assuming that we only run serialization on green code, the map will
either contain one compatible entry or no entries which makes the
additional check redundant.
Compilation crash must be handled separately in
`convertToConstantValues` method because we still want successfully
compile common code. All constants will be evaluated later on
fir2ir phase.
#KT-59362 Fixed