There was a problem with `reportDiagnosticOnce` method which was
called, for example, to report diagnostics about experimentalities. It
was crucial for code as in the issue (KT-34204).
The whole complexity was "count of experimental diagnostics" multiply
"count of all diagnostics" multiply very large constant. Almost on
each `reportDiagnosticOnce` method `readonlyView()` was called which
in turn called computation of cache. During cache computation we were
iterating through the all diagnostics and also were using
KotlinSuppressCache, which is not very fast.
#KT-34204 Fixed
This fixes the problem where compiling a class initializer that contains
a call to an `assert`ing function in a separate module causes the
assertion to always be enabled (i.e. the attached test used to fail in
CompileKotlinAgainstInlineKotlin mode).
Generally, using state.classFileVersion would be enough because we
report an error when inlining bytecode into a class file with a lower
target version (see INLINE_FROM_HIGHER_PLATFORM). However, we take maxOf
with the original version of the class file, _just in case_ the user has
suppressed this error (for example, to workaround some other corner case
in the compiler).
#KT-30744 Fixed
CheckLocalVariablesTableTests will now check the validity of
the locals table against types of locals computed based on the
bytecode.
These checks and the new destructuringInFor test act as a
regression test for the changes in
https://github.com/JetBrains/kotlin/pull/2613
These checks also caught a similar issue for destructuring
lambda parameters, where the local is introduced before the
value has been written to the local slot. This change also
fixes that.
Finally, this change fixes the asmLike tests to correctly
look up the name of parameters in the locals table.
If the delegated property operators involved are inline, and delegated
property metadata parameter is not used (which is often the case, e.g.,
'lazy'), we can skip those properties in metadata generation.
NOT implemented: special case when only 'kProperty.name' is used by the
corresponding delegated property operators.
Also a sneak fix for KT-34060.
If the scope for a local variable is started before a value
has been written, another value from a previous use of the local
slot can be present. That value could have a different type which
would lead to weird debugging situations and also leads to other
tools (such as D8) rejecting the locals information as it is
invalid.
Fixes KT-33959.
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
Steven Schäfer