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.
These line number tests only tested that a set of line numbers where
present in the java bytecode. Not that they would be hit in the
right order by the debugger. Moving them to stepping tests fixes that.
This exposes a couple of issues (in particular around try-catch-finally)
that should be fixed.
A number of tests are marked as failing now. Will investigate and
work on fixes next.
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
Since 1.4.0-dev-8774, we mangle functions returning inline class values,
including functions with return type 'kotlin.Result'. This causes
incompatibility when 1.4 compiler is used with 1.3 (or just some
pre-1.4.0-dev-8774) standard library.
Also, write "message from the future" on functions returning inline
class values indicating that they can be used since compiler version 1.4
(otherwise 1.3 compiler using 1.4 stdlib would fail to find some
@InlineOnly functions such as 'Result.success' and 'Result.failure').
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.
Dmitry Petrov