This is needed because we have different visibility rules for different
platform visibilities (e.g. protected and package private on JVM), so
we need ability to configure visibility checks for different platforms
This is needed to remove dependencies from fir modules to
`:core:descriptors` module
What was extracted:
- Modality
- ClassKind
- org.jetbrains.kotlin.name package
Before this commit, we generated fake overrides at last FIR2IR stage,
after having all functions and classes built. This could lead to a
situation when fake override was called before it was generated.
This commit fixes this situation.
Fix report about leaked projects on build server:
via 'com.intellij.psi.impl.PsiManagerImpl.myProject'; Value: 'Project (name=light_temp, containerState=DISPOSE_COMPLETED, componentStore=/mnt/agent/temp/buildTmp/ideaProject_test_1285163057398451250/testRootGW1/unitTest_addPrimaryConstructorParameter/light_temp....' of class com.intellij.openapi.project.impl.ProjectImpl
via 'com.intellij.psi.impl.source.PsiFileImpl.myManager'; Value: 'com.intellij.psi.impl.PsiManagerImpl@4ecdfe8' of class com.intellij.psi.impl.PsiManagerImpl
via 'com.intellij.psi.impl.source.tree.CompositeElement.myWrapper'; Value: 'DummyHolder' of class com.intellij.psi.impl.source.JavaDummyHolder
via 'com.intellij.psi.impl.source.tree.TreeElement.myParent'; Value: 'Element(DUMMY_HOLDER)' of class com.intellij.psi.impl.source.tree.FileElement
via 'com.intellij.psi.impl.source.SubstrateRef$2.val$node'; Value: 'Element(VALUE_PARAMETER)' of class com.intellij.psi.impl.source.tree.CompositeElement
via 'com.intellij.extapi.psi.StubBasedPsiElementBase.mySubstrateRef'; Value: 'com.intellij.psi.impl.source.SubstrateRef$2@5d02fa19' of class com.intellij.psi.impl.source.SubstrateRef$2
via 'kotlin.Pair.first'; Value: 'VALUE_PARAMETER' of class org.jetbrains.kotlin.psi.KtParameter
via 'org.jetbrains.kotlin.idea.codeInsight.upDownMover.KotlinExpressionMover.parametersOrArgsToMove'; Value: '(VALUE_PARAMETER, VALUE_PARAMETER)' of class kotlin.Pair
via '?'; Value: 'org.jetbrains.kotlin.idea.codeInsight.upDownMover.KotlinExpressionMover@7a6f128e' of class org.jetbrains.kotlin.idea.codeInsight.upDownMover.KotlinExpressionMover
via 'com.intellij.openapi.extensions.impl.ExtensionPointImpl.myExtensionsCacheAsArray'; Value: '[Lcom.intellij.codeInsight.editorActions.moveUpDown.StatementUpDownMover;@276493b6' of class [Lcom.intellij.codeInsight.editorActions.moveUpDown.StatementUpDownMover;
via 'java.util.concurrent.ConcurrentHashMap$Node.val'; Value: 'com.intellij.statementUpDownMover' of class com.intellij.openapi.extensions.impl.InterfaceExtensionPoint
via '?'; Value: 'com.intellij.statementUpDownMover=com.intellij.statementUpDownMover' of class java.util.concurrent.ConcurrentHashMap$Node
via 'java.util.concurrent.ConcurrentHashMap.table'; Value: '[Ljava.util.concurrent.ConcurrentHashMap$Node;@724e0cae' of class [Ljava.util.concurrent.ConcurrentHashMap$Node;
via 'com.intellij.openapi.extensions.impl.ExtensionsAreaImpl.extensionPoints'; Value: '{com.intellij.embeddedTokenHighlighter=com.intellij.embeddedTokenHighlighter, org.intellij.groovy.expectedTypesContributor=org.intellij.groovy.expectedTypesContributor, org.jetbrains.kotlin.resolveSco...' of class java.util.concurrent.ConcurrentHashMap
via 'com.intellij.serviceContainer.ComponentManagerImpl.extensionArea'; Value: 'Application (containerState=ACTIVE) (Unit test) (Internal) (Headless) (Command line)' of class com.intellij.openapi.extensions.impl.ExtensionsAreaImpl
via '?'; Value: 'Application (containerState=ACTIVE) (Unit test) (Internal) (Headless) (Command line)' of class com.intellij.openapi.application.impl.ApplicationImpl
(from ApplicationManager.getApplication())
In 1.3.x, for inline class member inline vals 'getFoo-impl' method was
generated in corresponding inline class.
Since 1.4.0, getters for properties returning inline class values are
mangled (so corresponding getters are named 'getFoo-<mangling_hash>'.
However, to maintain backward compatibility with libraries compiled with
1.3.x, inliner should be able to find 'getFoo-impl' method in the
bytecode.
...in class members. The corresponding classes end up nested in the
class initializer of the surrounding class and we need to take this into
account when creating instances of ClassCodegen.
This fixes KT-40332 on the JVM IR backend.
This patch performs the following changes:
1. Create synthetic tasks even if synthetic projects are
not supported on the current host. This change simplifies
configuring dependencies between these tasks and custom user
tasks at the user side.
2. Disable synthetic tasks if synthetic projects are not supported
on the current host
Issue #KT-40834 Fixed
The main change here is that when kotlin-reflect is being run under Java
9+, we use another implementation of BuiltInsResourceLoader (see
libraries/reflect/api/src/java9) which loads .kotlin_builtins files from
the java.lang.Module instance of kotlin-stdlib, instead of the class
loader of kotlin-reflect, which may not have access to those resources.
If the application is being run in the old (classpath) mode, that Module
represents the unnamed module, which contains everything on the
classpath, and everything works as before. But if it's being run in the
modular mode, that Module instance is an encapsulated module for
kotlin-stdlib classes and resources, exactly where .kotlin_builtins
files are located.
This fixes a regression in 1.4.0. Prior to 1.4, kotlin-reflect and
kotlin-stdlib were not named modules (see KT-21266) and were loaded as
_automatic_ modules even if the application was run in the modular mode.
Apparently, they shared the same class loader in that case and looking
up .kotlin_builtins resources worked.
This change was supposed to go alongside
828cc6dbf3, but was overlooked because
adding module-info to standard libraries was postponed at that point.
Also slightly refactor Java9ModulesIntegrationTest to simplify running
compiled code, and add a smoke test on using kotlin-reflect in modular
mode.
#KT-40842 Fixed
Dmitriy Novozhilov