Otherwise, we have a static initialization loop, leading to null-leaks
Removing default interface method indeed disconnects the loop, as per JVM
Specification, "5.5 Initialization".
See KT-33245 for detailed explanations
^KT-33245 Fixed
Relates to KT-8834, we continue reducing differences between old and new
inference. Note that as for `SamConversionPerArgument`, this feature
is enabled in the compiler and not in the IDE to avoid breaking code
for those users that already enabled new inference in the compiler
Under COMPOSITE mode we don't have a globally known way to create
built-ins, instead, we have to create them on per-module basis.
So, in this commit we:
1. Use builtInsProvider: (ModuleInfo) -> KotlinBuiltIns instead of
precomputed builtIns instance, in order to be able to calculate
builtIns on per-module basis
2. Introduce new entity, called BuiltInsCache, which, roughly
speaking, is a map of form ModuleInfo -> KotlinBuiltIns, to prevent
creation of multiple builtInsInstances
NB. Actually, it's of form BuiltInsCacheKey -> KotlinBuiltIns, because
we shouldn't create new builtIns for each module. Also, currently,
each platform has its own BuiltInsCacheKey implementation, because
parameters by which built-ins are created, are a bit different across
different platforms. Ideally, we should eliminate those differences
and they use one concrete implementation as a key.
As consequence, remove IdePlatformKindTooling.resolverForModule, because
it became more than just field, and it duplicates similar API in
IdePlatformKindResolution anyways
- implement error result
- refactor other result classes
- implement handling in the script evaluation extension - also restores
previous script error reporting functionality
- add possibility to customize result fileds in script and REPL
- refactor result calculation in the backend: cleanup, rename (since
it is not only about REPL now)
This reverts commit 674badc6
Since idea 192.5587.17 idea has own InjectedLanguageManager registration
and fails because of duplicate.
org.junit.ComparisonFailure: exception: org.picocontainer.defaults.DuplicateComponentKeyRegistrationException: Key com.intellij.lang.injection.InjectedLanguageManager duplicated
at com.intellij.util.pico.DefaultPicoContainer.registerComponent(DefaultPicoContainer.java:123)
at com.intellij.util.pico.DefaultPicoContainer.registerComponentInstance(DefaultPicoContainer.java:331)
at com.intellij.mock.MockComponentManager.registerService(MockComponentManager.java:89)
at org.jetbrains.kotlin.cli.jvm.compiler.KotlinCoreEnvironment$ProjectEnvironment.registerJavaPsiFacade(KotlinCoreEnvironment.kt:162)
at com.intellij.core.JavaCoreProjectEnvironment.<init>(JavaCoreProjectEnvironment.java:55)
at org.jetbrains.kotlin.cli.jvm.compiler.KotlinCoreProjectEnvironment.<init>(KotlinCoreProjectEnvironment.kt:27)
...
Before 5b7cee6221 JVM CLI compiler
was calling `KotlinToJVMBytecodeCompiler.compileBunchOfSources`.
`compileBunchOfSources` detected possible main classes,
and filled the Main-Class attribute in output jar
if if there was only one candidate.
After the change JVM CLI began calling
`KotlinToJVMBytecodeCompiler.compileModules`, which was not searching for a main class.
This change adds searching for main classes to `compileModules`.
We search for a main class only when one module is compiled,
and an output is written a jar file (so the change only affects JVM CLI compilation).
#KT-32272 Fixed
If new inference is enabled only for IDE analysis, then this feature
will be disabled to reduce difference between new and old inference,
but if new inference is enabled in the compiler, then this feature
will be enabled too to preserve behavior of new inference for
compilation
#KT-32175 Fixed
#KT-32143 Fixed
#KT-32123 Fixed
#KT-32230 Fixed
In 192 it's important to have service registered since
https://github.com/JetBrains/intellij-community/commit/f204718c885034bc2fa4be4b281ff4bbd5fa4ef4
Caused by: java.lang.IllegalArgumentException: Argument for @NotNull parameter 'value' of com/intellij/openapi/util/UserDataHolderBase.putUserDataIfAbsent must not be null
at com.intellij.openapi.util.UserDataHolderBase.$$$reportNull$$$0(UserDataHolderBase.java)
at com.intellij.openapi.util.UserDataHolderBase.putUserDataIfAbsent(UserDataHolderBase.java)
at com.intellij.openapi.util.NotNullLazyKey.getValue(NotNullLazyKey.java:41)
at com.intellij.lang.injection.InjectedLanguageManager.getInstance(InjectedLanguageManager.java:41)
at com.intellij.psi.impl.PsiCachedValue.isVeryPhysical(PsiCachedValue.java:74)
at com.intellij.psi.impl.PsiCachedValue.anyChangeImpliesPsiCounterChange(PsiCachedValue.java:57)
Reproduced with Fir2IrTextTestGenerated
Previously, a lot of clients used JvmPlatform as platform-marker,
without thinking about jvmTarget.
For the sake of migration, this commits introduced so-called
UnspecifiedJvmPlatform, which can be used for a time being, but
generally, all usages should be removed in future.
Previously, containers set-up was performed by calls to static functions
like 'createContainerForLazyResolve', which would set-up whole container
from scratch.
This has several issues:
- complicates code re-use and encourages copy-paste of one and the same
set-up logic
- complicates composition of multiplatform containers (because each
set-up method relies on the fact that it should take an empty
container and compose it completely)
The idea of this commit is to split set-up methods into smaller ones,
with finer areas of responsibility, which allows to re-use them
in various scenarios (and, in particularly motivating composition
of multiplatform container)
Essentially, this function was used solely for setting
'useBuiltInsProvider' to 'true'; otherwise it were just delegating to
createContainerForLazyResolveWithJava, which were just increasing the
noise.
This is a large commit, which introduces general API for working with
abstraction of Platform.
- Add new abstraction to 'core' - SimplePlatform - which represents
exactly one platform
- Clients are strongly prohibited to create instances of SimplePlatform
by hand, instead, corresponding *Platforms abstraction should be used
(e.g. JvmPlatforms, JsPlatforms, KonanPlatforms)
- Move TargetPlatform to 'core', it represents now a collection of
SimplePlatforms
- Clients are strongly encouraged to use TargetPlatform
(not SimplePlatform) in API, to enforce checks for multiplatform
- Provide a helper-extensions to work with TargetPlatform
(in particular, for getting a specific component platform)
- Remove MultiTargetPlatform in favour of TargetPlatform
- Notably, this commit leaves another widely used duplicated abstraction,
namely, IdePlatform. For the sake sanity, removal of IdePlatform is
extracted in the separate commit.
Svyatoslav Kuzmich