Basically, just calculate them the same
way it's done for other members.
`chooseIntersectionVisibilityForSymbolsOrNull`
is named like this to prevent a JVM clash.
^KT-66046 Fixed
Use the receiver and context receiver types in addition to the property
name as cache keys for the synthetic property generation.
Also, fix logic that searches for accessor overrides by comparing
receiver and context receiver types.
Finally, let synthetic properties delegate their receiverParameter and
contextReceivers to their accessors.
#KT-65464 Fixed
#KT-66195
The following tests are failing with exceptions and will be fixed in the
following commits
j+k/testKjkPropertyAndExtensionProperty.kt
j+k/testKjkImplicitReturnType.kt
#KT-62118 Fixed
lambdaParameterForBareTypeEarlyFixationAffectsBehavior.kt
should show in the future commits how early variable fixation
necessary for bare type information might affect inference results
^KT-64840 Related
Right now, during the process of inlining, the compiler erases types.
Because of that, we can end up with some random type
(for example, `Any`) where the concrete type was
expected (for example, `Int`). Compiler must insert a cast in the
required places.
#KT-66017 Fixed
outside of constructor.
In other words, when EXACTLY_ONCE lambda initializes non-static final
field of a class, the lambda has to be inlined, otherwise, backend
generated separate function of separate class for the lambda,
which lead to exception at runtime.
#KT-64854 Fixed
#KT-59906 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)
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
Vladimir Sukharev