See the test data.
ISE happened because at some point after incomplete `getValue` resolution
of `a` property, we updated in the `transformAccessors` the property type
to the `Variable(Y)` type and then used it as a 3rd argument for
`setValue` call which is incorrect because the variable belongs
to a different constraint system (from `getValue`).
Mostly, the fix is just a repeating K1 behavior, namely postponing
`setValue` resolution until delegate inference is completed.
^KT-59066 Fixed
There are some cases for fake-override actualization which become
prohibited in the new expect/actual model, so few tests start to fail,
despite the fact that they are checking entirely different things
In terms of MPP there are no such thing as `expect constructor` for enums,
but they are physically exist in FIR and IR, so we need a switch which
skips matching for them
FE 1.0 implementation did not touch to avoid any hidden changes
Also use TypeSystemContext instead of TypeSystemInferenceExtensionContext
in AbstractExpectActualCompatibilityChecker
This is needed to have an ability to implement ExpectActualMatchingContext
for IR backend. IrTypeSystemContext may operate with type substitutors,
but there is no sense to implement all methods from TypeSystemInferenceExtensionContext
in it
- Get rid of `AbstractExplicitReceiver` (as there is no explicit usages of it)
- Get rid of `AbstractExplicitReceiverValue` (as there is only one inheritor of it)
- Make `ReceiverValue` an abstract class
This is needed because of mutable nature of receiver values: implicit
receiver values can be modified because of smartcasts, but in candidate
we need to store snapshot of receiver in the form it was at the beginning
of the resolution
^KT-58823 Fixed
This field cached expansion of type of implicit receiver, which is incorrect,
because type of receiver may change because of smartcasts, but this field
was immutable
To properly resolve qualifier parts in the middle,
we need to resolve the whole qualifier to understand
which parts of the qualifier are package or class qualifiers.
And then we will be able to resolve the qualifier
selected by the user to the proper class, package or callable.
^KT-59189
1. Optimize it by removing a tower data context collection (KT-59189)
2. Rework the behavior, so it simulates the tower resolve by returning the set of symbols only from the first tower level, which is not empty
^KT-59189 fixed
Relates #KT-57647
If a serialization descriptor is used in the companion, then when accessing the child elements, an array of cached child serializers may be read.
Since the serialization plugin adds its declarations to the class after the declarations from the source code, the initialization of the array of child serializers occurs after the execution of the user code.
This can lead to N PE errors when trying to access an unfilled cached child serializer.
The solution is to change the order of declarations so that the declaration with the property of cached child serializers comes first.
Merge-request: KT-MR-10545
Merged-by: Sergey Shanshin <Sergey.Shanshin@jetbrains.com>
This avoids that the thread sweeping the base object can get stale
locals, in the case that the finalizer thread unlinks the extraobject at
the same time. This is done by moving the responsibility of unlinking
the extraobject to the sweeping of the base object.
Co-authored-by: Troels Bjerre Lund <troels@google.com>
Merge-request: KT-MR-10518
Merged-by: Alexander Shabalin <Alexander.Shabalin@jetbrains.com>
Additionally, deprecate -Xgc in favour of a new binary option "gc".
This will allow setting gc right in gradle.properties
Merge-request: KT-MR-10498
Merged-by: Alexander Shabalin <Alexander.Shabalin@jetbrains.com>
Generating IR declarations for use-site substitution overrides leads
to IR that is different from K1 as well as problems in signature
generation which relies on mangling. Use-site substitutions can contain
references to type parameters from the call-site which aren't handled
in mangling.
#KT-57022 Fixed
In gradle it is possible to add dependency to configuration which
is resolved to itself. It is possible due to nature of Configuration
that can contain both: dependencies and artifacts. When configuration
has dependency on itself, it practically means that this dependency
will be resolved to configuration's artifacts.
LazyResolvedConfiguration should be capable to handle such dependencies
Android preset needs to be removed in favor of Android Pluggable Target
Changes were originally introduced by commit:
becf50ee0f
but then, unfortunately, reverted due to binary compatibility issues
^KT-59049 Verification Pending
^KT-57903 Verification Pending
This reverts commit becf50ee
These changes are binary incompatible due to move of methods with
default arguments.
^KT-59049 In Progress
^KT-57903 In Progress
See 2e5b783cc6 for details
After the fix for KT-57694 (mostly rewritten JvmMappedScope),
the behavior of loading new JDK 21 members of K2 has been aligned with K1
Pavel Mikhailovskii