Since property accessor descriptors (unlike corresponding IR elements)
do not have type parameters, we need to take them from the corresponding
property to ensure the correct IR for delegated property accessors.
Alternatively, we could improve the lookup utilities and their usages to
always find the exact override of a symbol from
Collection/Iterable/CharSequence/etc, but since we need to load the
original symbol anyway in cases when the loop subject's type is a type
parameter, we might as well simplify everything and always reference the
original symbol.
Also improve exception message and removed unused declarations in
IrBackendUtils.kt.
Call transformer previously ran completion of argument atoms
only for non-error candidates. This led to missing diagnostics,
i.e. from collection literal resolver.
Now arguments of calls resolved to error descriptor are completed,
with exception to not found provideDelegate calls.
provideDelegate's subatoms are not completed after failure, because
it is a part of delegate competion, which does not end with
unresolved provideDelegate.
Completing after provideDelegate failure removes constraint system
from resolved arguments, which breaks resolve for get/setValue.
^KT-33592 Fixed
* JVM incorrectly mapped T<KClass<...>> to T<Class<...>> because the
annotation-ness of the type mapping mode was inherited one level
down into a generic signature independent of T
* JVM_IR was even worse as it did not use VALUE_FOR_ANNOTATION at all,
mapping T<T<KClass<...>> to T<T<Class<...>> as well.
The correct behavior is to map KClass to Class only at top level or as
an argument of Array.
For example, synthetic `$annotations` methods for properties were
previously mangled to `$annotations-...`, which breaks annotation
loader, and fails an assert in ClassCodegen.generateMethod.
Normally, the fact that is was Unit was not visible as enum constructors
are lowered to normal class constructors anyway. The exception is when
the arguments are reordered, causing the incorrect return type to leak
into the block that holds temporary variables.
This corresponds to the ABI generated by the old backend. Moreover, when
compiling the module 'ir.tree' with JVM IR (could not reproduce on a
small sample), this led to a codegen crash when trying to reassign
parameter value to the default stub, which is an error expression and
can't be generated by ExpressionCodegen.
Like the old backend, always leave private @JvmDefault annotated
interface members (properties, methods) on the interface, just like
the old backend. Fix naming, and introduce test to document the naming
scheme.
- introduce a scoped counter instead of a global one for name
generation for accessors. Naive solution not working.
- Introduced hardcoded "jd" suffix for accessors on interfaces, under
the assumption that the only such accessors are due to JvmDefault
and their bridges from `$DefaultImpls`. Removed all associated
templated tests, so the old and IR backend correspond on this matter
again.
- Respecialized writeFlags from regexps to string-equality: we are
going for exact matches now!
- Fixed package calculation in `IrUtils.kt`.
- Accessors for static members must be due to accessing super
classes. Actual super-qualified calls are naturally also accessing
super classes. Hence the `$s+{hashcode(superClassName)}`
suffix. Added test to affirm this naming scheme.
- Field getters/setters for static fields must be companion accessors,
otherwise just labelled as accessors. They are also tagged with `s`
suffix when accessing static fields.
- For naming of accessors to coincide with the old backend, field
renaming to avoid JVM signature clashes must be done _after_
generation of accessors for those fields.
Change the treatment of default implementations on interfaces in JVM
compatibility mode. Previously, the IR backend moved the actual
default implementation to the DefaultImpls class, and then bridged to
it from the interface default. The old backend did the reverse, at the
cost of an additional accessor, in order to gain better binary
compatibility properties. See #2612 for discussion.
The accessor needs to call a specific implementation, so must be
performed through an `invokespecial`. We trick the
SyntheticAccessorLowering into doing this for us, by marking the
bridging call as a super call. We do this in want of an explicit
`invokespecial` Ir Node.
InterfaceDefaultCallsPhase previously assumed the old behaviour of the
IR backend (that calls to default implementations, e.g. `foo$default`
should target `DefaultImpls.foo$default`). But now the bridge to
foo$default resides on `DefaultImpls` already, causing that pass to
create a recursive loop. We cut that loop with a simple check.
In case of inline it should be same descriptor (except of fake override), In general case getter could be synthetic accessor and in such case it's not inline
In old BE we generate `create` for this kind of suspend lambdas, which,
like in simple suspend lambdas is responsible for putting arguments
(including extension receiver) to fields.
But, if number of parameters of suspend lambda (including receiver) >= 1,
there is no need to generate `create`, since `create` is called only by
`createCoroutine` and friends from stdlib, and there is no version of
`createCoroutine` for lambdas with multiple parameters.
Thus, in old BE we generate a redundant method, which affects method
count.
In JVM_BE we decided to 'inline' create into `invoke` for suspend lambdas
with multiple parameters.
Unresolved reference diagnositc was not reported on callable references
returned from if or when expression because of additional block wrapper.
^KT-30953 Fixed
With NO_LOCKS strategy we can easily end up in a situation when
constraint system for a generic call is built incorrectly,
producing flaky errors (or don't produce errors at all)
Now proper storage manager is injected for all cases except:
- IR
- Codegen
- Serialization plugin
- Fake local objects
Most likely, NO_LOCKS strategy for these cases is fine as at that point
the compiler works in one thread
#KT-34786 Fixed
Updated test checks, that large unsigned numbers are converted to corresponding
negative signed numbers properly. Using unsinged constants instead of signed
in test allows to remove supressed OI error as well as use test with NI.
Vararg parameter in reflection type is interpreted as covariant
array type against array in expected functional type and as
vararg element type otherwise. For instance having function
fun foo(vararg args: Int): Unit { /*...*/ }
reference ::foo can be passed against expected
(Int) -> Unit,
(Int, Int) -> Unit, etc.
In none of such cases type for parameter in foo's reflection type
should be changed to array.
However, against expected type (IntArray) -> Unit args' type
must become IntArray.
^KT-25514 Fixed
* Extract replacement of IrGetField/IrSetField into a separate
file-level lowering (should reduce the amount of work to linear in
the number of classes rather than potentially quadratic)
* Extract static backing field construction into JvmDeclarationFactory
and move that lowering after PropertiesToFields lowering to reduce
code duplication
Check worked incorrectly in case when argument type and expected type are the
same intersection type, which is possible for local variables without explicit
type declaration.
Georgy Bronnikov