This feature is not needed because it is unconditionally disabled for K1
(because of not fully correct implementation) and unconditionally enabled
in K2 (K2 does not support old behavior)
^KT-38895
Incompatible supertypes check also don't provoke runtime problems
in most situations, because this check is also bound to type argument
conflict. Related to KT-54411
The situations with conflicting type arguments normally don't provoke
any runtime problems. Also, conflicts like A<T> VS A<SomeType> aren't
valid at all. Here we decided to remove them to avoid strange
and non-actionable warnings in user code.
#KT-54411 Fixed
The original idea was in resolving of annotation type ref using only
importing scopes and accepting or discarding that resolution result
depending on if this annotation is needed for compiler/plugins or not
But there is a problem that resolution of FirUserType with type resolver
is not a pure operation: type resolver transforms qualifier parts which
may contain type arguments, so if they were unresolved at the first
resolve, they will stay unresolved forever. To prevent this we will
deeply copy annotation type ref before first resolution
^KT-55286 Fixed
In K1 analogue of `K2_VISIBILITY_ERROR` is `K1_RUNTIME_ERROR`, so
candidates with `K2_VISIBILITY_ERROR` should win over innaplicable
candidates with `INAPPLICABLE`, `INAPPLICABLE_ARGUMENTS_MAPPING_ERROR`
or `INAPPLICABLE_WRONG_RECEIVER` applicability
This is needed to allow resolution to invisible symbols (and later
suppress error with `@Suppress("INVISIBLE_SYMBOL", "INVISIBLE_REFERENCE")`
^KT-55026 Fixed
^KT-55234
Enable custom allocator with -Xallocator=custom.
If the gc is cms (default):
* a patched version of the memory manager is used that does not build a
list of allocated objects.
* a patched version of the cms is used that defers to the allocator for
sweeping.
Otherwise, a warning is printed, and the allocator is used using the
standard api.
Design doc:
https://docs.google.com/document/d/15xMp-nE-DWL8OrtOc8DoXB80AHUphFICEGjj5K0aNFc
Co-authored-by: Troels Lund <troels@google.com>
Merge-request: KOTLIN-MR-546
Merged-by: Alexander Shabalin <alexander.shabalin@jetbrains.com>
is called. Some kotlin plugins (for example JS) re-use
DefaultKotlinSourceSet class for their source sets. However
DefaultKotlinSourceSet has an API that is connected to IDE import
particularly `getDependenciesTransformation`. Since Kotlin/JS doesn't
support metadata dependencies, and their transformations as well
we should lift strong requirement for compileDependenciesTransformation
to be set for each source set. Instead, just return empty list of
transformations.
^KT-55347 Verification Pending
Pure JS projects should still be able to import even thus calling
`getDependenciesTransformation` should not throw any runtime exceptions
and results should be empty. Since JS projects doesn't support metadata
dependencies transformations.
^KT-55347 In Progress
Ilya Kirillov