CheckLocalVariablesTableTests will now check the validity of
the locals table against types of locals computed based on the
bytecode.
These checks and the new destructuringInFor test act as a
regression test for the changes in
https://github.com/JetBrains/kotlin/pull/2613
These checks also caught a similar issue for destructuring
lambda parameters, where the local is introduced before the
value has been written to the local slot. This change also
fixes that.
Finally, this change fixes the asmLike tests to correctly
look up the name of parameters in the locals table.
If the delegated property operators involved are inline, and delegated
property metadata parameter is not used (which is often the case, e.g.,
'lazy'), we can skip those properties in metadata generation.
NOT implemented: special case when only 'kProperty.name' is used by the
corresponding delegated property operators.
Also a sneak fix for KT-34060.
The changes introduced 471134d31e are only needed
for the case of HMPP project while for other cases it might break the behavior
a bit like in KT-34027
See org.jetbrains.kotlin.resolve.calls.results.OverloadingConflictResolver#filterOutEquivalentCalls
Before 471134d we were comparing
"fun foo(x: String)" with "[substituted] fun foo(x: String)"
and areCallableDescriptorsEquivalent returned false for such case.
Thus, both overrides were left in the resulting set.
After 471134d, those two descriptors
becamed considered as equal thus having a possibility to remove any of them.
The problem is that "areCallableDescriptorsEquivalent" has kind of
unclear contract. Effectively it checks whether two descriptors match
to the same declaration
But straightforward fixing of this exact call-site (using original descriptors)
doesn't help: behavior might change in a very subtle way (see org.jetbrains.kotlin.spec.checkers.DiagnosticsTestSpecGenerated.NotLinked.Dfa.Pos#test72)
So, the main idea is changing the contract for areCallableDescriptorsEquivalent
only when project is HMPP one.
^KT-34027 In Progress
Previously, ResolverForProjectImpl had multiple callbacks in
constructor. Some of those callbacks were used only to overcome module
visibility and provide an ability to inject IDE-specific logic into
compiler (ResolverForProject is in the 'compiler'-module)
This commit introduces abstract class which implements
environment-independent logic (previously, this logic had been stored in
ResolverForProjectImpl) with several abstract met hods (previously,
callbacks). Then, we provide few concrete implementations of
AbstractResolverForProject with clear semantics:
- IdeaResolverForProject: resolver used in IDE, where we have indices,
oracles, multiple modules, etc.
- ResolverForSingleModuleProject: resolver for project with only one
module, commonly used for CLI compiler/tests
- one anonymous implementation for MultimoduleTests
This refactoring achieves several things:
- now it is easier to see what kinds of ResolverForProject you might see
in some particular environment (previously, one had to inspect all
call-sites of constructor)
- we can easily add IDE-specific logic in IdeaResolverForProject without
adding noisy callbacks (which most probably wouldn't have any other
non-trivial implementations)
When using JDK11, generating stubs for enums is broken.
This commit handles the faulty generation by JDK11 by
fully printing enums in custom implementation of tree
printing.
Test: added JDK11 tests for KAPT stub generation
Using same directory for android (user home) leads to exception on Windows
because of file lock:
com.google.gson.JsonSyntaxException: java.io.IOException: The process cannot access the file because another process has locked a portion of the file
at com.google.gson.Gson.fromJson(Gson.java:942)
at com.google.gson.Gson.fromJson(Gson.java:865)
at com.android.tools.analytics.AnalyticsSettings.loadSettingsData(AnalyticsSettings.kt:140)
at com.android.tools.analytics.AnalyticsSettings.initialize(AnalyticsSettings.kt:211)
at org.jetbrains.android.AndroidPlugin.initializeForNonStudio(AndroidPlugin.java:56)
at org.jetbrains.android.AndroidPlugin.initComponent(AndroidPlugin.java:30)
at com.intellij.openapi.components.impl.ComponentManagerImpl$ComponentConfigComponentAdapter.getComponentInstance(ComponentManagerImpl.java:503)
at com.intellij.openapi.components.impl.ComponentManagerImpl.createComponents(ComponentManagerImpl.java:126)
at com.intellij.openapi.application.impl.ApplicationImpl.load(ApplicationImpl.java:411)
at com.intellij.idea.IdeaTestApplication.a(IdeaTestApplication.java:114)
at com.intellij.idea.IdeaTestApplication.getInstance(IdeaTestApplication.java:61)
at com.intellij.idea.IdeaTestApplication.getInstance(IdeaTestApplication.java:54)
at com.intellij.testFramework.LightPlatformTestCase.initApplication(LightPlatformTestCase.java:166)
at com.intellij.testFramework.fixtures.impl.LightIdeaTestFixtureImpl.setUp(LightIdeaTestFixtureImpl.java:41)
at com.intellij.testFramework.fixtures.impl.CodeInsightTestFixtureImpl.lambda$setUp$27(CodeInsightTestFixtureImpl.java:1142)
at com.intellij.testFramework.EdtTestUtil$Companion$runInEdtAndWait$1.invoke(EdtTestUtil.kt:18)
at com.intellij.testFramework.EdtTestUtil$Companion$runInEdtAndWait$1.invoke(EdtTestUtil.kt:13)
at com.intellij.testFramework.EdtTestUtilKt.runInEdtAndWait(EdtTestUtil.kt:63)
at com.intellij.testFramework.EdtTestUtil$Companion.runInEdtAndWait(EdtTestUtil.kt:18)
at com.intellij.testFramework.EdtTestUtil.runInEdtAndWait(EdtTestUtil.kt)
at com.intellij.testFramework.fixtures.impl.CodeInsightTestFixtureImpl.setUp(CodeInsightTestFixtureImpl.java:1141)
at com.intellij.testFramework.fixtures.LightJavaCodeInsightFixtureTestCase.setUp(LightJavaCodeInsightFixtureTestCase.java:96)
at org.jetbrains.kotlin.idea.test.KotlinLightCodeInsightFixtureTestCase.setUp(KotlinLightCodeInsightFixtureTestCase.kt:66)
at com.intellij.testFramework.UsefulTestCase.defaultRunBare(UsefulTestCase.java:388)
at com.intellij.testFramework.EdtTestUtil$Companion$runInEdtAndWait$1.invoke(EdtTestUtil.kt:18)
at com.intellij.testFramework.EdtTestUtil$Companion$runInEdtAndWait$1.invoke(EdtTestUtil.kt:13)
at com.intellij.testFramework.EdtTestUtilKt$runInEdtAndWait$3.run(EdtTestUtil.kt:67)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:301)
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:758)
at java.awt.EventQueue.access$500(EventQueue.java:97)
at java.awt.EventQueue$3.run(EventQueue.java:709)
at java.awt.EventQueue$3.run(EventQueue.java:703)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:74)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:728)
at com.intellij.ide.IdeEventQueue.dispatchEvent(IdeEventQueue.java:433)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:205)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)
Caused by: java.io.IOException: The process cannot access the file because another process has locked a portion of the file
at sun.nio.ch.FileDispatcherImpl.read0(Native Method)
at sun.nio.ch.FileDispatcherImpl.read(FileDispatcherImpl.java:61)
at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223)
at sun.nio.ch.IOUtil.read(IOUtil.java:197)
at sun.nio.ch.FileChannelImpl.read(FileChannelImpl.java:159)
at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:65)
at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:109)
at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:103)
at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284)
at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)
at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
at java.io.InputStreamReader.read(InputStreamReader.java:184)
at com.google.gson.stream.JsonReader.fillBuffer(JsonReader.java:1295)
at com.google.gson.stream.JsonReader.nextNonWhitespace(JsonReader.java:1333)
at com.google.gson.stream.JsonReader.consumeNonExecutePrefix(JsonReader.java:1576)
at com.google.gson.stream.JsonReader.doPeek(JsonReader.java:534)
at com.google.gson.stream.JsonReader.peek(JsonReader.java:425)
at com.google.gson.Gson.fromJson(Gson.java:923)
... 41 more
#KT-33870 Fixed
In IDE with have descriptors with additional annotations obtained from
external annotations manager. They are probably only java overrides so
shouldn't be present in stubs, thus must be ignored in this test.
Tests with enums started to fail after upgrading to 192 platform because
of additional NotNull annotation on `getDeclaringClass()` method.
#KT-33732 Fixed
Introduce file attributes cache, which is only applicable when no dependencies are cached in memory cache
Refactor ScriptDependenciesCache to memory cache that is able to get configuration from cache and checks if it is up to date
Move all public methods to ScriptDependenciesManager
Introduce ScriptClassRootsManager that checks if root change event should be called after script configuration update
Useful for tests that check behavior which depends on having a recent
API version enabled, and that don't want to depend on a specific fixed
API version (to prevent eventual obsoletion)
To mimic the case of user passing an explicit "-api-version" flag to
avoid API version being inferred to the version of stdlib in
dependencies by JvmRuntimeVersionsConsistencyChecker
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
Unlike previously, this optimisation works on every callee return type.
Tail-calls inside unit functions can be either
INVOKE...
ARETURN
or
INVOKE
POP
GETSTATIC kotlin/Unit.INSTANCE
ARETURN
The first pattern is already covered. The second one is a bit tricky,
since we cannot just assume than the function is tail-call, we also need
to check whether the callee returned COROUTINE_SUSPENDED marker.
Thus, resulting bytecode of function's 'epilogue' look like
DUP
INVOKESTATIC getCOROUTINE_SUSPENDED
IF_ACMPNE LN
ARETURN
LN:
POP
#KT-28938 Fixed
Stack Trace
at kotlin.collections.CollectionsKt___CollectionsKt.first(_Collections.kt:184)
at com.intellij.configurationStore.XmlSerializer.<clinit>(xmlSerializer.kt:15)
at com.intellij.codeInsight.CodeInsightSettings.writeExternal(CodeInsightSettings.java:228)
at com.intellij.testFramework.UsefulTestCase.<clinit>(UsefulTestCase.java:104)
at com.intellij.testFramework.TestLoggerFactory.log(TestLoggerFactory.java:154)
at com.intellij.testFramework.TestLogger.info(TestLogger.java:70)
at org.jetbrains.kotlin.scripting.compiler.plugin.definitions.CliScriptDependenciesProvider.calculateRefinedConfiguration(CliScriptDependenciesProvider.kt:45)
...
annotationsViaActualTypeAliasFromBinary.kt is ignored because
ExpectActualRemover can't find actual for the expected constructor of
Anno now, because `ExpectedActualResolver.findActualForExpected`
incorrectly filters out actual declarations without any source file, and
Java classes loaded in the fast mode don't have any source files.
This will need to be fixed separately, probably by making
ExpectedActualResolver look for the actual class of an expected class
member first (with source file-based filtering), and then
unconditionally locating the corresponding member there
After b602c08773, this test started to put all .java files to the
dependencies when compiling .kt files, _in addition_ to the already
compiled class files from those Java sources. This is incorrect because
the test should actually check how Kotlin compiles _against_ Java
binaries. The other behavior (compiling against Java sources) is already
supported and used in normal box tests with .java sources.
However, we can't simply filter out all .java files before calling
`super.doMultiFileTest` because many of those contain directives
(WITH_RUNTIME, FULL_JDK, etc.) and we should load them in
`CodegenTestCase.compile`. As a workaround, remove '.java' file
extension to prevent their compilation but still be able to resolve
directives.
This commit doesn't change behaviour of any inference algorithm, it
introduces opportunity to switch constraint system that is used for
overload resolution and fix problematic cases by changing one enum
entry.
Due to fundamental changes, there are cases where a new inference
algorithm reports overload resolution ambiguity errors (#KT-31670,
#KT-31758), which is correct from its point of view. However, this is
a breaking change and to really make it, we should be very confident
and have enough motivation for it, therefore, we don't change behavior
now in order to collect more examples (if there are any). And if we
find a lot of erroneous examples, we'll be able to change the behavior
quite simply
- implement wrappers to wrap old and new API providers and resolvers
- make old API deprecated (with error where possible)
- drop old internal classes related to the old API
- refactor usages accordingly
- fix and add missing features to the scripting API where necessary
Mads Ager