classes, instead of MemberScope.
The primary motivation was to fix issues around type-mapping for inline
classes in FIR, which uses wrapped descriptors that have empty
MemberScopes.
In the newly added test, prior to this change, JVM IR was generating
DefaultImpls classes with calls to things like
`kotlin/collections/MutableList$DefaultImpls.spliterator` and other
default methods present in JDK 8+. This obviously didn't make much
sense. Although these weren't explicitly mentioned anywhere in the
bytecode, they caused some validation tools to report errors (e.g.
animalsniffer used in arrow).
Don't mangled functions annotated with @JvmName.
Annotate 'Result.success' and 'Result.failure' with @JvmName and
@Suppress("INAPPLICABLE_JVM_NAME").
NB this would require bootstrap.
The test used to fail because it has an augmented assignment for
elements in a HashMap of Strings, and "plus" fails to resolve due to
ambiguity: besides String.plus, BigDecimal.plus in the standard
library is also considered. BigDecimal is not resolved and thus
isError returns true. During type checking, the context has
isErrorTypeEqualsAnything set to true, and BigDecimal is now regarded
as a super type of String and BigDecimal.plus is a valid
candidate. Adding the directive "FULL_JDK" enables resolving of
BigDecimal so that BigDecimal.plus is excluded.
If an inline parameter has a default value, its type is nullable.
There's already code to handle this in `IrInlineCodegen`, but it
really should be in `isInlineParameter` instead, otherwise e.g.
SyntheticAccessorLowering fails.
There are multiple ways to declare a named variable-like entity in
Kotlin:
1. val/var variable declaration
2. destructuring declaration
3. parameter of a function
4. parameter of a lambda
5. destructured lambda parameter
6. for-loop's variable declaration
7. catch block exception declaration
8. val in when
9. field declaration
Out of them, only variable and field can be assignable, in other words,
they can be on the left hand side of an assignment.
Val/var variable declarations were already supported.
So, we needed to just support field initialization and tell the backend
that other ways are prohibited. Function and lambda parameters were
already been supported. So, the only thing to explain to the backend are
remaining ways.
#KT-39113 Fixed
#KT-34048 Fixed
For the same reason as in the previous commit: descriptors are cached
via weak references in moduleByClassLoader.kt and can be
garbage-collected at any point. So different instances of KParameterImpl
representing the same parameter may store different instances of
descriptors.
Descriptors are cached via weak references in moduleByClassLoader.kt and
can be garbage-collected at any point. So relying on identity of
descriptors in KTypeParameterImpl is dangerous because the same type
parameter can be represented by different descriptors. For example, the
test equalsOnFunctionParameters.kt was flaky before this change because
of this issue, and that could be reproduced by running it a few hundred
times in the same process.
Instead, use the type parameter's container (which is either KClass or
KCallable) and name, in equals/hashCode. KClass and KCallable already
have equals/hashCode independent of descriptors, so this works in case
the descriptor is invalidated.
If the primary constructor has a vararg parameter, the corresponding
property has an array type. This commit creates the builtin array
types for such properties if the vararg element type is primitive,
e.g., CharArray instead of Array.
Ilmir Usmanov