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
To create a smart psi type pointer, IJ Platform uses resolve.
We cannot use resolve from JavaSymbolProvider, as it may lead to resolve contract violation.
^KT-59133 fixed
KtResolveExtensions are designed to handle IDE analysis use cases where
source might not be available at analysis time, because that source is
generated by an external source generator, such as an annotation
processor or resource compiler. The sources generated by those external
generators can appear in the analysis scope, and cause issues with
source clash - resolution may find the virtual source from the
KtResolveExtension, the on-disk generated source from the external
generator, or both. This can cause issues, because that on-disk
generated source may be stale, and may not have symbols that will exist
the next time the generator is run (or, conversely, may have symbols
that will disappear on the next build).
To solve this, add a `getShadowedScope(): GlobalSearchScope` to
`KtResolveExtension`. Any files in the module that are included in that
scope will be hidden from resolution, allowing the resolve extension to
cleanly replace those files.
^KT-58834 fixed
It's very slow and leads to performance problems (see KT-58125)
Instead, we do the following:
- For a fully resolved type qualifier, when we want to resolve its part,
we are looking for the corresponding symbol by traversing nested classes
bottom up.
- For an error qualifier, we are trying to resolve the maximum possible
qualifier in the types transformer where all the type scopes are
already available.
^KT-58125 fixed
Dmitriy Novozhilov