Instead of using raw List types in the Gradle extension, ListProperty
should be used instead to make it more Gradle idiomatic. Also marking
the extension and all properties as experimental to allow easier
changing in the future.
^KT-65952 Fixed
^KT-64187 Fixed
Review: https://jetbrains.team/p/kt/reviews/14807
I also checked that IDE sets metadataCompilation to `true` (Actually, it
looks like IDE performs analysis two times with the flag having
different values, but whatever, maybe it's even better this way)
Review: https://jetbrains.team/p/kt/reviews/14807
Motivation: no motivation, I was just passing by and noticed this bug.
It looks like this commit doesn't affect any tests
After legacy light classes were removed, the only remaining usage was in
KotlinLightClassBuilderFactory where we ran JVM backend in the
LIGHT_CLASSES mode, and that was only used from diagnostic tests to
report JVM backend diagnostics.
We don't actually need to build stubs here, so we can just use ASM's
class writer, which means that StubClassBuilder and all its dependencies
can be removed.
Even ones inside inline functions. This was a backwards compatibility
hack for Kotlin 1.4, where the inliner would crash if it attempted to
regenerate an anonymous object with no SMAP; that has been fixed in 1.5,
and ever since then trivial SMAPs could be inferred from line number
markers in methods.
There are three kinds of changes to tests in this commit:
* Some SMAPs are gone entirely - self-explanatory.
* Some SMAPs have narrower line ranges - that's because the old SMAP
had the range for the entire file, while the new one only maps up to
the last line number used in the class. There should be no
difference in behavior.
* Some "source file name" markers are removed in continuation objects
- continuations don't have any line numbers, so there's no debugging
information anyway. The actual source information is in the
containing class.
To be more precises, ResultTypeResolver for K2 now searches for
similar LOWER/UPPER constraints pair based on the same flexible type,
like LOWER(CapturedType&Any..CapturedType?) and UPPER(CapturedType!).
If such a pair is found, the CapturedType is not approximated.
This is done to avoid a big difference between this case and
completely same constraints, like LOWER(CapturedType!) and
UPPER(CapturedType!). In this case we squash them to EQUAL(CapturedType!)
even before ResultTypeResolver, and captured types which is got from
an EQUAL constraint are not approximated even before this commit.
This commit fixes back a case from KT-50134 and a problem with intellij.vcs.git
#KT-65596 Fixed
This commit changes the behavior of KT-59138 effectively declining it in 2.0.
However, we plan to implement KT-59138 behavior under a feature
flag in 2.0 (see KT-66447), and switch this feature on version 2.x.
Also, this commit implements the LC resolution about postponing
KT-57014 change. We don't have KT-57014 described behavior in 2.0 anymore.
However, we plan to implement a deprecation warning here, see KT-65578.
After this commit, 6 diagnostic tests become incorrectly broken:
- 5 tests from PurelyImplementedCollection group
- a test platformTypes/nullableTypeArgument.kt
This commit also breaks currently fixed-in-k2 KT-50134
(it is fixed again in the following commits),
as well as KT-58933 (it will remain not fixed till we enable KT-59138
behavior again).
#KT-65596 In Progress
#KT-57014 In Progress
#KT-58933 Submitted
Annotation arguments cannot contain declarations, so we can use empty
SymbolRemapper instead of DeepCopySymbolRemapper because the latter
introduces some overhead.
#KT-66281
Rename it to `deepCopyWithoutPatchingParents`, move to
`org.jetbrains.kotlin.ir.util`, make it inline+reified, and extract the
common implementation with `deepCopyWithSymbols` into `deepCopyImpl`.
At this point, `deepCopyWithVariables` is the same as
`deepCopyWithSymbols` except that the former doesn't call
`patchDeclarationParents`, which most likely produces incorrect IR in
some call sites.
Dmitrii Gridin