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.
Account for JsExport in legacy backend namer. It means we
catch overloaded exported function conflicts for free!
Add error diagnostics:
* NESTED_JS_EXPORT (Fixes KT-36798)
* WRONG_EXPORTED_DECLARATION (Part of the fix for KT-37752)
* NON_EXPORTABLE_TYPE (Fixes KT-37771)
Fix compilation errors, revealed by this fix.
SmartCastManager is unnecessary for error reporting, intermediate diagnostics from the NI contain all required infromation.
When SmartCastManager is used it leads to missing unstable smart casts in case of expressions with captured types.
This happens, because data flow info is recorded for original expression without captured types, which is used as a key.
DataFlowValues created from receivers with captured types can't be used to retrieve that info.
^KT-39010 Fixed
- Allow participating subtypes of functional types in conversions
- Fix several subtle inconsistencies
- Place logic about conversions at one place
Now conversions operations have two stages: before usual subtyping
check and after one. This is needed to support conversions of
subtypes (of functional types, for example). First, the compiler
checks if it possible to resolve an argument without conversion and
only then it tries to perform conversion.
Note that it'd be incorrect to perform conversion eagerly as it can
change resolve (Runnable & () -> Unit <: KRunnable), plus we can't
guess whether conversion is needed at all as it's important not to
look into supertypes if resolution doesn't actually needed it
#KT-36448 Fixed
#KT-37574 Fixed
#KT-38604 Fixed
When we generate call for 'foo', we make decision about invoking
a 'foo$default' too late, after the call arguments are generated.
If 'foo' was an override, and base class (interface) was generic,
'foo' in base class could have a different Kotlin and JVM
signature, so the arguments we generated could be generated wrong
(primitive or inline class values instead of boxes, see KT-38680).
Also, we always selected first base class in supertypes list,
which caused KT-15971.
Look into resolved call and see if we should actually call
'foo$default' instead of 'foo' when determining actual callable.
Overrides can't introduce default parameter values, and
override-equivalent inherited methods with default parameters
is an error in a child class. Thus, if we are calling a class
member function with a default parameters, there should be one
and only one overridden function that has default parameter values
and overrides nothing.
Attributes are used to name continuation classes and are generated
before inline classes processing. During the processing, for override
functions in inlined classes, the compiler generates
STATIC_INLINE_CLASS_REPLACEMENT function with body of the override.
The override's body is replaced with delegating call to
STATIC_INLINE_CLASS_REPLACEMENT. However, since we need to keep the name
of the continuation class, we copy attributes from the override to
STATIC_INLINE_CLASS_REPLACEMENT. This leads to attribute clash during
AddContinuationLowering.
So, to fix the issue, do not use the attribute of
STATIC_INLINE_CLASS_REPLACEMENT in original->suspend map.
As an optimization, do not generate continuation for the override
function.
Nikita Bobko