Thus, KT-55586 is being postponed, too.
The reasoning behind this change is that the language-committee issue
has not been approved yet, so new annotation package can't be enabled
by default, but it seems that it doesn't make sense having
a different behavior for the old one but at least that would make them
work consistently, so we postpone them, too.
Previously, the semantic was more-or-less correct for most of the cases
but some corner one, like `sort` in MutableList didn't work properly.
Namely, `sort` should be marked there in a way to forbid to call it
everywhere beside super-calls.
Also, overriding it should be allowed.
Mostly, the logic was re-written to K2 model from K1-related
JvmBuiltInsCustomizer.
^KT-57694 In progress
^KT-57269 Fixed
- This change is a prerequisite for allowing combined Java symbol
providers (in LL FIR) to correctly disambiguate classpath order after
getting classes with a combined scope, as the index access of the
combined Java symbol provider is not guaranteed to return the class
that should be first based on the original dependency order. To be
able to disambiguate, a combined Java symbol provider needs access to
all class candidates the index can find.
- `FirJavaFacade.knownClassNamesInPackage` cannot be computed in the IDE
using the current strategy because there are multiple finders and
there is no `CliFinder`. However, the cache was still used, which
caused it to be filled with `null` values and additionally caused
worse performance in `JavaSymbolProvider` due to hash map accesses via
`hasTopLevelClassOf`.
- Rewriting the strategy is non-trivial as additional indices are needed
on the IDE side. See KTIJ-24642.
FunctionalTypeKind can be used in FE 1.0 too, so there is no need to
keep both classes. Also, removal of FunctionClassKind simplifies work
with FunctionalTypeKind in common code, like Analysis Api
To make it available for dynamically attached JVMTI agents.
`@SourceDebugExtension` annotation value is equal to the
SourceDebugExtension attribute value, which is checked now for all box
tests. The difference is that the annotation stored in the constant
pool, which is available for dynamically attached JVMTI agents.
#KT-53438 Fixed
But still compile stdlib, reflect, kotlin.test and scripting runtimes
with JVM target 1.6 to simplify migration from Kotlin 1.6 to 1.7.
#KT-45165 Fixed
This is much more correct, because we have one to one mapping for
special java functions in this case, so using single nullable name
instead of list of names makes code more readable