Since KotlinTypeMapper is no longer used in the JVM IR backend, we need
not run CodegenBinding.initTrace and check that names of local entities
are exactly equal to local names computed by that algorithm.
However, it's still useful as an opt-in flag, to discover issues where
unwanted elements take part in the naming (such as temporary IR
variables, see for example cb2e68fece). So we introduce a new command
line argument -Xir-check-local-names which, when the IR backend is used
(via -Xuse-ir), launches the name computation algorithm from the old
backend and then compares that the names are exactly equal to the names
computed by the IR backend in InventNamesForLocalClasses.
As well as mapFieldSignature, mapReturnType, mapAsmMethod and smaller
methods. This removes yet another dependency on KotlinTypeMapper in the
IR backend.
Make ReifiedTypeInliner and related classes generic over the
KotlinTypeMarker subtype (KotlinType or IrType), add a typeSystem to get
arguments/nullability and other properties of types regardless of their
representation, but still fall back to KotlinType when generating the
actual bytecode of other intrinsics (as/is)
Instead of calling enormously complicated
KotlinTypeMapper.mapToCallableMethod, where most of special cases are
handled in the IR backend via lowerings.
The old compiler will crash if it tries to inline a function that's
passing a lambda parameter into the new parameter null check method
`Intrinsics.checkNotNullParameter` because that usage is not considered as
inlinable by the old compiler (it only knows about
`Intrinsics.checkParameterIsNotNull`). Therefore we require that these
functions can only be read by compilers of version 1.3.50 or greater.
#KT-22275 Fixed
Similarly to previous commit, this method was unused since its
introduction before 1.0, so we're changing its semantics to throw NPE
and starting to use it with API version >= 1.4.
#KT-22275 In Progress
This method was introduced in c204e8fc67 "just in case" and was never
used. Therefore we're free to change its semantics and use it in all new
generated code (with API version >= 1.4), without even worrying that the
newly used API will leak from inline functions in stdlib when used with
an older API version. Since we agreed to change the type of thrown
exceptions to java.lang.NPE in KT-22275, invoke a new method
throwJavaNpe now which throws that exception instead of KNPE.
Note that the additional method that takes an exception message is still
unused and exists just in case we need to use it in the future. The new
method throwJavaNpe is public also "just in case" we need to invoke it
in the future; currently it's not invoked from the bytecode.
#KT-22275 In Progress
Previously it was linear scan, failing on unbalanced suspension markers.
Now, I use CFG to find end markers, which are reachable from start
markers. Using CFG allows to walk through suspension point instructions
only, since they form region.
If, for some reason, end marker does not exist (inliner or unreachable
code elimination pass remove unreachable code) or is unreachable,
just ignore the whole suspension point, as before.
#KT-33172 Fixed
#KT-28507 Fixed
We're going to start using this method since 1.4 for parameter null
checks, and without this change the compiler would fail if it
encountered a call to such method on a lambda parameter inside an inline
function, since that call is not inlinable.
#KT-22275 In Progress
Before this commit, line numbers were only available on 'when' clause bodies.
So, if a clause condition check didn't succeed, the entirely clause could be ignored.
In the old JVM backend, JvmSerializationBindings are created per
ClassBuilder, and special care must be taken to make sure that
JVM-specific metadata ends up in the correct bindings. This is
especially relevant for declarations whose metadata is moved to other
classes away from the place where the original declaration lies, for
example properties moved from companion object to the outer class, or
synthetic methods for annotation properties in interfaces moved to
DefaultImpls, or const properties in multifile parts moved to the
facade.
In the JVM IR backend, this seems not necessary and actually it's
complicated to ensure that we use the correct ClassBuilder for bindings
(see the code simplification in ClassCodegen). Therefore, in case we
don't have an easy way to retrieve the correct ClassBuilder instance, we
now write all JVM-specific metadata to the new _global_ bindings map in
GenerationState, which is used by JvmSerializerExtension as a fallback
if the ClassBuilder's local map has no relevant key.
Steven Schäfer