If the super class is in a file that has already been lowered, the base
method has an extra continuation parameter which breaks things.
Also, SAM wrappers around functional objects are tail-call and do not
need continuations ever, so don't even try.
^KT-50950 Fixed
Test data in `box/annotations/typeAnnotations` is changed because nested
classes in type annotations are rendered differently in JDK 19
(`Outer.Nested` instead of `Outer$Nested`).
#KT-54116 Fixed
We already check for {POP, Unit} sequence before ARETURN, but if the
there are multiple sequence before ARETURN, the compiler assumes, that
TCO misses.
The fix is to check, that the instruction after the sequence is either
ARETURN or another {POP, Unit} sequence.
#KT-50835
#KT-54152 Fixed
This is a proposal to fix KT-49364.
Operand stack type verification happens before `checkcast`
is executed. When we implicitly cast an inline class
to a non-inline type, if type of stack value is not subtype
of the target, then coercing is necessary.
For non-suspend lambdas annotations are carried over to the
invoke method so that tooling can find the annotation there.
It seems reasonable that annotations are carried over to
the invokeSuspend method on suspend lambdas as well so that
similar tooling can be built and work for suspend lambdas.
The previous attempt stopped this code from throwing an exception during
serialization, but the arity is still wrong so an exception is now throw
when reading the serialized type.
^KT-50997 Fixed
After an accidental change in 846537b367, we started generating metadata
into anonymous classes for callable references. This metadata contained
the Kotlin representation of the referenced function. In KT-53794, this
led to a problem where Java's protected visibility could not be
represented in Kotlin terms, which crashed the backend.
But also, this metadata is useless because there's no real use case for
interpreting it (since you already have a function reference object at
runtime with all the needed information), so it would take some extra
space in the bytecode.
#KT-53794 Fixed
It's reported on receivers in extension function calls with stub type,
as such calls can shadow members of finalized stub types causing
change of resolve when corresponding type argument specified explicitly
It works by checking extension receiver during call resolution parts run
That way we can easily detect if we found an extension applicable to
stub receiver and report call diagnostic for it
KT-53739
There was an assumption that if receiver exists then parameter will
also exist. This is not true for references marked with `JvmStatic`.
Later in `JvmStaticInObjectLowering` dispatch receiver may be dropped.
Corresponding lowering creating wrappers from JS Backend was used.
Also, the lowering was changed to create local function, instead of
normal one in outer scope, as a lot of logic from local declarations
lowering should be duplicated otherwise for correct type parameters
handling.
^KT-38535
* Use ReflectionFactoryImpl as single point of synchronization
* Synchronize all cache-sensitive tests on it in order to be robust in parallel test runners
* Remove redundant cache clear after each test
Merge-request: KT-MR-6842
Merged-by: Vsevolod Tolstopyatov <qwwdfsad@gmail.com>
Before this commit, we added Enum.entries only in case when
LanguageFeature.EnumEntries was ON (with an exception in K1/Java case).
In this commit we add Enum.entries unconditionally, and in case
the language feature is OFF we filter them out during tower resolve.
Leveraging the same mechanism with $EntriesMapping as Java enums.
Old (compiled with LV/AV < 1.8) enums are detected by looking for
static special <get-entries> method that cannot be introduced on
Kotlin enums otherwise
#KT-53236
There is no need to create honest object in case of such simple
calculation. Furthermore, it can be harmful if enum class has
non-constant initializer or property.
#KT-53480 Fixed
* Cache KType instances constructor from the given classifier
* For generics, cache KTypes with already substituted arguments
* It significantly speeds up all typeOf-based APIs, both accesses to typeOf and its related properties (i.e. classifier)
#KT-53508
Merge-request: KT-MR-6818
Merged-by: Vsevolod Tolstopyatov <qwwdfsad@gmail.com>
* It is a heavy-weight object that is hard to compute
* It is being constructed each type _cached_ method ref is used in equals/hashCode
* Module name is deliberately ignored, corresponding doc is added where appropriate
#KT-48136
Merge-request: KT-MR-6817
Merged-by: Vsevolod Tolstopyatov <qwwdfsad@gmail.com>
The test isn't passing when using K/N per-file caches and in order to fix it,
some hacks are required, which isn't worth it considering that test contains invalid code.
* Replace pcollections with ClassValue/ConcurrentHashMap-based caches
* Do not store weak references, instead cache strong references and count on ClassValue to unload the corresponding classloader if necessary
* ConcurrentHashMap does not rely on WeakReference as it's only selected on Android where classloader leaks don't exist
* Update reflect/scripting JDK requirement to Java 8 in order to proceed
#KT-53454
#KT-50705
Merge-request: KT-MR-6788
Merged-by: Vsevolod Tolstopyatov <qwwdfsad@gmail.com>
pyos