Duplicated messages in testdata appeared because default renderer
renders diagnostic spans ambiguously. It shows only start position.
In fact, there are 3 failures, 2 of them distinguish only by the
diagnostic end offset. See youtrack for more information.
The issue about inconvenient rendering is KT-64989.
#KT-64608
Since KT-53308, we started to cache results of typeOf invocation
in reflection. The cache uses the origin 'KClassifier' as a key with
an optional list of 'KTypeProjection' in type argument position,
and computed result as a value.
Without classifier check, the caching produces incorrect execution in
a very specific classloaders usage which is leveraged
by IDEA source-tree:
* All Kotlin stdlib and reflect classes are always loaded by the same
classloader
* Other classes that depend on Kotlin are loaded by separate
classloaders
The reproducer:
* Attempt to use typeOf<kotlin.List<Foo>> from one classloader caches
the resulting KType
* Attempt to use typeOf<kotlin.List<Foo>> from another classloader
for the same 'Foo' that differs only in classloader reuses the
computed KType, meaning that KType type argument classifier
is simply incorrect and points to the 'Foo' from the first classloader
#KT-54611 Fixed
#KT-54629 Fixed
Merge-request: KT-MR-7470
Merged-by: Vsevolod Tolstopyatov <qwwdfsad@gmail.com>
if it is called using parens and not by calling 'invoke' method.
Use underlying type when calling continuation constructor if suspend
function is method inside inline class.
#KT-43505 Fixed
#KT-39437 Fixed
inside 'create' if 'create' overrides 'create' from
BaseContinuationImpl. In other words, unbox the parameter if 'create'
accepts only one parameter.
#KT-43249 Fixed
#KT-43533 Fixed
inside 'invoke' if 'create' does not override 'create' from
BaseContinuationImpl. In other words, when suspend lambda accepts more
than one parameter (including receiver).
Do that only if we do not generate bridge 'invoke' method, since
inline classes are unboxed in the bridge.
Use mangled name for 'create' function in this case inside 'invoke'.
#KT-43249 In progress
#KT-39847 Fixed
#KT-38937 Fixed
Like function arguments, they are context-dependent, but unlike function
arguments, callable references should be resolved eagerly as if they are
explicit receivers.
Namely, remove incorporation “otherInsideMyConstraint” to eliminate
constraint system redundancy and produce a potentially very large number
of constructs.
Instead, introduce not so “spreadable” incorporation during variable
fixation (equality constraint with result type into other constraints).
^KT-41644 Fixed
^KT-42195 Fixed
^KT-42920 Fixed
^KT-42791 Fixed
^KT-41741 Fixed
- rename fileToPurenessInitializers onto fileToInitializerPureness
- remove redundant check on top-level property
[JS IR] Rename initialis* to initializ* for consistency
[JS IR] Move propertyLazyInitialization property to context from configuration
[JS IR] Add test on lazy initialization properties order
[JS IR] Add multi module for lazy initialization of properties
[JS IR] Move tests onto js.translator
[JS IR] Rename fileToInitializerPureness according to context name
^KT-43222 fixed
The debug experiece of destructuring patterns in lambdas is different
across the two backends due to the IR backend moving local variables
to fields.
However, since the destructuring variable is never actually visible in
the debugger (no linenumbers in the live range of the variable), and
the variable is never used for anything other than hiding it from the
debugger, we propose that it is not actually necessary to include it
in the LVT (and in fact, could be left out of the LVT on the old
backend).
1. Use 'x' for each parameter, which is not an inline class, every
possible clash is handled by signature rather than name. This change
makes more API changes binary-compatible. So, the changes are in line
with the vision of inline classes are value classes, like primitives.
2. Take return type into account when mangling a function if the return
type is inline class. Otherwise, boxing bridge will not be generated,
which leads to CCE at runtime.
Do not destructively update the @JvmStatic function, instead
create a copy on first access, and replace the original with
the copy in the jvm static lowering. This ensures that the original
function is seen in other lowerings independently of file lowering
order.
Evgeniy.Zhelenskiy