[JS IR] Move tests into compiler/testData
[JS IR] Add cyclic dependencies with lazy property initialization
[JS IR] Add test on not initialization in case of call non properties (classed, objects, enum classes, const vals)
[JS IR] Add initialization through top level
[JS IR] Ignore enum getInstance function in property lazy initialization
[JS IR] Use let function with useful result instead of pure apply and also
[JS IR] Remove duplicated tests in js.translator
References to properties with JvmStatic getter were not handled in
MakeCallsStatic (by overwriting dispatchReceiver with null) because the
property itself was not considered static.
#KT-43672 Fixed
... in case `-Xno-optimized-callable-references` is enabled. Before this
change, the generated abstract equals/hashCode methods were considered
as accidental overrides because they did not have equals/hashCode from
the supertype in the overriddenSymbols list.
#KT-43666 Fixed
1. When an annotation has multiple targets, the priority goes like this:
constructor parameter (if applicable) -> property -> backing field.
2. The argument to `kotlin.annotation.Target` is a vararg, so that
should be handled as well.
3. `AnnotationTarget.VALUE_PARAMETER` allows receivers, constructor
parameters, and setter parameters, while `AnnotationTarget.FIELD` allows
both backing fields and delegates.
Known issue: java.lang.annotation.Target is not remapped to the Kotlin
equivalent, so things are still broken for pure Java annotations.
if it is called using parens and not by calling 'invoke' method.
Use underlying type when calling continuation constructor if suspend
function is method inside inline class.
#KT-43505 Fixed
#KT-39437 Fixed
inside 'create' if 'create' overrides 'create' from
BaseContinuationImpl. In other words, unbox the parameter if 'create'
accepts only one parameter.
#KT-43249 Fixed
#KT-43533 Fixed
inside 'invoke' if 'create' does not override 'create' from
BaseContinuationImpl. In other words, when suspend lambda accepts more
than one parameter (including receiver).
Do that only if we do not generate bridge 'invoke' method, since
inline classes are unboxed in the bridge.
Use mangled name for 'create' function in this case inside 'invoke'.
#KT-43249 In progress
#KT-39847 Fixed
#KT-38937 Fixed
Before this commit, questionable optimization existed which
unwrapped string interpolating call with single argument to this argument.
However, this led to source element loss and the necessity of sub-hacks.
In this commit we dropped this optimization (anyway user can remove
this single-expression string template in code if needed) to keep
source elements intact.
Like function arguments, they are context-dependent, but unlike function
arguments, callable references should be resolved eagerly as if they are
explicit receivers.
- rename fileToPurenessInitializers onto fileToInitializerPureness
- remove redundant check on top-level property
[JS IR] Rename initialis* to initializ* for consistency
[JS IR] Move propertyLazyInitialization property to context from configuration
[JS IR] Add test on lazy initialization properties order
[JS IR] Add multi module for lazy initialization of properties
[JS IR] Move tests onto js.translator
[JS IR] Rename fileToInitializerPureness according to context name
^KT-43222 fixed
1. Use 'x' for each parameter, which is not an inline class, every
possible clash is handled by signature rather than name. This change
makes more API changes binary-compatible. So, the changes are in line
with the vision of inline classes are value classes, like primitives.
2. Take return type into account when mangling a function if the return
type is inline class. Otherwise, boxing bridge will not be generated,
which leads to CCE at runtime.
In cases when the test has the JVM_TARGET directive, use that one for
Java compilation as well.
Otherwise, for box tests, the corresponding test in `JvmTarget6OnJvm6`
(module `:compiler:tests-different-jdk`) will fail. However, it affects
all codegen tests, so fix a bunch of them which use Java 8+ features to
explicitly compile with JVM target 1.8. In particular, this obsoletes
the SKIP_JDK6 directive in those tests because "JVM_TARGET: 1.8" also
skips it for JDK 6.
The check for IS_SOURCE_6_STILL_SUPPORTED is needed in order to still be
able to run tests in the project while only having a single JDK > 11
installed, and having all of the env vars JDK_16, JDK_17, JDK_18
pointing to that JDK.
Do not destructively update the @JvmStatic function, instead
create a copy on first access, and replace the original with
the copy in the jvm static lowering. This ensures that the original
function is seen in other lowerings independently of file lowering
order.
Ilya Goncharov