The issue is that during binding fake overrides, the compiler doesn't
differ setters from its properties, so the compiler uses the same
visibility for setter and entire property.
Changing logic at the binding stage can cause some unpredictable consequences so
the fix is to do this differentiation right at the reporting stage
^KT-56662 Fixed
Merge-request: KT-MR-9565
Merged-by: Michail Zarečenskij <Mikhail.Zarechenskiy@jetbrains.com>
- `LLFirCombinedJavaSymbolProvider` combines multiple
`JavaSymbolProvider`s. Its advantages are: combined index access,
caching, classpath order disambiguation.
- Scopes can still be optimized with a combined scope instead of a naive
union scope.
^KT-57207 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.
- `javaFacade.findClass` is a potentially costly operation. This commit
extends `JavaSymbolProvider` and its class cache to accept an already
existing `JavaClass` if provided, circumventing the `findClass`
operation.
- `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.
Add a special annotation @JsExternalTypeArgument for
marking function parameters. The marked parameter
accepts an argument with an external type only.
^KT-57479 Fixed
Some of the incoming paths "absoluteness" may not match the
one of the corresponding library path, and that leaded to incorrect
filtering out some items in the deserialized symbol providers.
Fix the filtering to account for the mismatch.
#KT-57535 fixed
Align it with all other element types where origin is mutable.
This was left unchanged previously probably because the
IrMemberAccessExpression was not handled by the tree generator.
This fixes a scenario when INVISIBLE_REFERENCE is suppressed, but we
resolved to the wrong overload because when none of the candidates were
applicable, more or less the first one was chosen.
Because we call `fullyProcessCandidate` on the candidates, their
applicability can change which can lead to a situation where the
applicability of a ConeAmbiguityError is different to all its
candidates. The changes in coneDiagnosticToFirDiagnostic.kt account for
that, otherwise code like candidates.first { it.applicability ==
CandidateApplicability.UNSAFE_CALL } can throw NoSuchElementException.
#KT-57776 Fixed
Review: https://jetbrains.team/p/kt/reviews/9562
This commit fixes IdeaJsr223Test in kotlin plugin. The test failure was
caused by b50a803b6f commit where we
dropped `put(JVMConfigurationKeys.JDK_HOME, ...)` from
`configureJdkClasspathRoots`. Ilya Chernikov says that it's incorrect to
set JDK_HOME in `configureJdkClasspathRoots`.
To reproduce the test failure:
1. Update `.idea/libraries/kotlinc_kotlin_dist.xml` and
`.idea/libraries/kotlinc_kotlin_jps_plugin_classpath.xml` with new
Kotlin (in other words: bump bundled JPS)
2. Run the test
Test failure stacktrace:
```
javax.script.ScriptException: error: cannot access 'java.io.Serializable' which is a supertype of 'kotlin.Int'. Check your module classpath for missing or conflicting dependencies
y.first() + 2
^
at org.jetbrains.kotlin.cli.common.repl.KotlinJsr223JvmScriptEngineBase.asJsr223EvalResult(KotlinJsr223JvmScriptEngineBase.kt:104)
at org.jetbrains.kotlin.cli.common.repl.KotlinJsr223JvmScriptEngineBase.compileAndEval(KotlinJsr223JvmScriptEngineBase.kt:63)
at org.jetbrains.kotlin.cli.common.repl.KotlinJsr223JvmScriptEngineBase.eval(KotlinJsr223JvmScriptEngineBase.kt:31)
at java.scripting/javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:262)
at org.jetbrains.kotlin.idea.repl.IdeaJsr223Test.testJsr223Engine(IdeaJsr223Test.kt:31)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at junit.framework.TestCase.runTest(TestCase.java:177)
at com.intellij.testFramework.UsefulTestCase.lambda$runBare$11(UsefulTestCase.java:479)
at com.intellij.testFramework.UsefulTestCase.lambda$wrapTestRunnable$13(UsefulTestCase.java:500)
```
It was working incorrectly, because we've been trying to fix
P1 variable to intersectTypes(String?, StubForP2) that should result
to String? because we've got stubEqualsToAnything enabled there,
but nullability was being chosen incorrectly because
`StubForP2.isNullableType()` returned false
NB: The code inside `is ConeTypeVariable` case wasn't working properly
because it always `lookupTag.toSymbol(session)` always returned null,
thus there was effectively five dead lines of code there.
^KT-57814 Fixed
^KT-57921 Related
Due to changes in 9dcd40d7b7
classpath and pluginClasspath arguments become Arrays
Now we need to update arguments representation to properly deserialize
it
^KT-57927
During extracting type attributes from annotations we should expand
typealiases of annotation type to handle cases when user makes a typealias
on some special annotation, like `kotlin.internal.Exact`. And to exapnd
typealias we should resolve annotation class id to symbol.
This leads to a cycle during class deserialization, if some nested annotation
is used as type annotation in some declaration in the same class
```
interface SomeInterface {
interface NestedInterface : @Ann Some
interface Some
@Target(AnnotationTarget.TYPE)
annotation class Ann
}
```
Attempt to find symbol for SomeInterface.Ann during deserialization of
SomeInterface.NestedInterface wil lead to second attempt to deserialize
class SomeInterface, which eventually leads to StackOverFlow. And at the
same time expanding typealiases for annotations from binaries has not
much sense, because types in binaries are already expanded
So to fix this issue it's enough to just not expand typealiases on type
annotations for types of deserialized declarations
^KT-57876 Fixed
Evgeniy.Zhelenskiy