This PR also updates the min agp version we test with because older agp
versions are using gradle apis which doesn't exist in gradle 6.0+.
GH PR: #4155
Started as a result of postponed jdk dispose
71e7449
CodeInsightTestFixtureImpl assertPointersAreDisposed is invoked before
actually removing pointers.
com.intellij.openapi.util.TraceableDisposable$DisposalException: 1708093728
at com.intellij.openapi.util.TraceableDisposable.getStackTrace(TraceableDisposable.java:121)
at com.intellij.openapi.vfs.impl.VirtualFilePointerTracker.assertPointersAreDisposed(VirtualFilePointerTracker.java:86)
at com.intellij.testFramework.fixtures.impl.CodeInsightTestFixtureImpl.lambda$tearDown$38(CodeInsightTestFixtureImpl.java:1281)
at com.intellij.testFramework.RunAll.collectExceptions(RunAll.java:57)
at com.intellij.testFramework.RunAll.runAll(RunAll.java:35)
at com.intellij.testFramework.fixtures.impl.CodeInsightTestFixtureImpl.tearDown(CodeInsightTestFixtureImpl.java:1234)
at org.jetbrains.kotlin.idea.codeInsight.gradle.GradleQuickFixTest.tearDownFixtures(GradleQuickFixTest.kt:41)
at org.jetbrains.kotlin.idea.codeInsight.gradle.ExternalSystemTestCase.lambda$null$5(ExternalSystemTestCase.java:185)
Started as a result of postponed jdk dispose
71e74497b5
CodeInsightTestFixtureImpl assertPointersAreDisposed is invoked before
actually removing pointers.
com.intellij.openapi.util.TraceableDisposable$DisposalException: 1708093728
at com.intellij.openapi.util.TraceableDisposable.getStackTrace(TraceableDisposable.java:121)
at com.intellij.openapi.vfs.impl.VirtualFilePointerTracker.assertPointersAreDisposed(VirtualFilePointerTracker.java:86)
at com.intellij.testFramework.fixtures.impl.CodeInsightTestFixtureImpl.lambda$tearDown$38(CodeInsightTestFixtureImpl.java:1281)
at com.intellij.testFramework.RunAll.collectExceptions(RunAll.java:57)
at com.intellij.testFramework.RunAll.runAll(RunAll.java:35)
at com.intellij.testFramework.fixtures.impl.CodeInsightTestFixtureImpl.tearDown(CodeInsightTestFixtureImpl.java:1234)
at org.jetbrains.kotlin.idea.codeInsight.gradle.GradleQuickFixTest.tearDownFixtures(GradleQuickFixTest.kt:41)
at org.jetbrains.kotlin.idea.codeInsight.gradle.ExternalSystemTestCase.lambda$null$5(ExternalSystemTestCase.java:185)
For most of those the behaviour isn't set in stone, though at the moment
of making that commit we're more or less sure that it's reasonable.
Behaviour in some cases might be more strictly enforces (as much as you
can enforce something in esoteric cases with misconfigured project
sturcture). Those are marked with comments with '!'.
Note the behaviour in 'precisePlatformsWithUnrelatedModuleHmpp': it is
incorrect, as set of platforms still contains unrelated platforms.
This is because in the current solution, some source-sets
(commonMain/commonTest) always receive COMMON platform and then it gets
coerced to set of targets actually seen in the project.This helps if
projects uses as much targets as current module (like in
precisePlatformsHmpp), but fails if it uses more targets than the
current module (like in precisePlatformsWithUnrelatedModuleHmppp)
The upcoming commits will fix that issue
Use {de,}capitalizeAsciiOnly and to{Lower,Upper}CaseAsciiOnly where
possible, and stdlib's functions with Locale.US everywhere else.
Otherwise, if the default system locale is Turkish, the capital latin
letter "I" is transformed in toLowerCase to "ı" (see
https://github.com/JetBrains/kotlin/blob/66bc142f92085047a1ca64f9a291f0496e33dd98/libraries/stdlib/jvm/test/text/StringJVMTest.kt#L119),
which for example breaks the codegen for `intArrayOf` in
KT-25400/KT-43405.
Similarly, lower case latin letter "i" is transformed to "İ".
#KT-13631 Fixed
#KT-25400 Fixed
#KT-43405 Fixed
Basically, the former uses an old quickly-scrapped infrastructure,
which were not applicable for HMPP, so the latter tests were written.
So, both check for one and the same thing (highlighting in MPP projects),
but MultiplatformAnalysisTest is more modern,
and has a lot of inconvenient stuff in MultiplatformHighlighting fixed
^KT-43116 Fixed
Android gradle-project model differs from what we have for pure Java
and MPP. It's the reason why application classpath cannot be collected
correctly.
Until universal solution is provided delegation to gradle is put under
the registry flag. If disable platform runner is used as before.
Behaviour is similar to the test suite gutters:
- simple triangle when there is no history
- triangle + red circle if some runs failed
- triangle + green circle if all runs passed
^KMM-100 Fixed.
Approach to take classpath from 'project.sourceSets' failed because it
was applied to extra modules - those without java like plugins
(extending project model with 'sourceSets').
This commit specifies criterion of gradle-project selection - the one to
create run task for.
^KT-42561 fixed
Nikolay Krasko