parameters of inline function. Otherwise, it leads to AnalyzerException,
when inlined lambda contains try-catch block. The reason is simple:
in try block, we leave some variables on stack, while on catch block the
stack is empty. Spilling the variables before try block does the trick.
#KT-34708 Fixed
* fixed NoSuchMethod caused by mismatched signatures of the "invoke" method generated for lambda arguments
* added test cases in invoke.kt for KFunction and anonymous functions
* added a transformer to wrap the last expression in the bodies of lambdas with return
Otherwise EnhancedNullability annotation instance is lost (for some
reason it's not translated to IR elements), and in the newly added test,
the wrapper type in Java is confused with primitive, and this causes
a platform declaration clash error.
Also make IrTypeArgument.eraseTypeParameters private, since it's not
used outside.
Otherwise, on creating suspend function views these functions will clash
with interface ones. Instead, compute name of their continuation classes
based on attributes of the interface class.
Now AddContinuationLowering is responsible for both adding continuation
classes to suspend functions and adding continuation parameters to
them.
Because we cannot create a view if inline suspend function is defined
in another file, we generate a stub without body when we encounter call
to it. And then, when we lower the file containing the function we add
the body. This way we have no unlowered views after the lowering.
Thus, after the lowering there should be no suspend function, which
are not views, therefore, remove VIEW origins.
Because transformations of suspend functions can copy them into another
object, use attribute as a key inside function to view map.
Don't insert implicit null check on a value of @EnhancedNullability type
used where @EnhancedNullability type is expected.
This uncovers a bunch of other problems in FE and BE.
KT-36343 and KT-36347 are bugs in StrictJavaNullabilityAssertions
implementation which should most likely be fixed in next major language
version (with proper breaking change notice).
KT-36344 is a design problem which should be addressed after 1.4 issues
are resolved.
Also use updated diagnostic pattern in TreesCompareTest.
In rare cases diagnostic was cut too early on !> characters,
that were a part of diagnostic parameter:
<!DIAGNOSTIC("Type<DefinitelyNotNullTypeArgument!!>")!>
This ensures correct generation of generic signatures in the resulting
byte code, but it _is_ a work in progress: the actual type *arguments*
passed for these parameters during compilation are dummy `Any?` types.
Sites that need more work are indicated with TODO's.
- copy type parameters of interfaces to methods moved to DefaultImpls
- implement type parameter renaming scheme from JVM, with proper
renaming and substitution.
- adjust call sites in bridges in classes->DefaultImpls
- adjust call sites in bridges from DefaultImpls->Interface
- adjust call sites in bridges from DefaultImpls->DefaultImpls
- adjust super calls ->DefaultImpls
- adjust calls in code of Interfaces->DefaultImpls
Otherwise, it's complicated to work with nested lambdas:
outer/inner ones may be replaced independently and still refer
to the old one instances.
So in the changed test, if we don't apply the commit, will remain
implicit return and receiver types for the nested lambda
Anyway, once we decided to leave immutable semantics,
replacements are not necessary anymore
This way we're making sure that the copied field has some associated
property, where we can get the value of isConst flag from. That flag is
later used in StaticInitializersLowering to determine whether we need to
erase initializer of a field. The tests are unmuted because now the
initializer is correctly _not_ erased. (They were passing before
switching master to 1.4 because without
NoConstantValueAttributeForNonConstVals, we treated all static fields
with primitive/string values as const, and never erased initializers
because of that.)
Before fix only one level of type arguments was used to determine variance of type variable to find out direction requirements.
This incorrect in general case, because outer variance affects subtyping deductions, for example:
Inv<Out<A>> <: Inv<Out<B>> => A <: B; B <: A, despite A and B are in covariant position if only one level is considered
^KT-36233 Fixed
Generate the expression with the original type and then insert
an implicit conversion. That matches the behavior of psi2ir
better and therefore avoids breaking backend assumptions.
In particular, IrGetValue expects the type of the underlying
symbol and the type of the IrGetValue to be the same.
Final default properties accessors that access a backing field
on the same class can be replaced by direct field use.
Perform the optimization late in the pipeline to allow lowerings
to expose more opportunities for optimizations.
Anton Bannykh