Revert "`KotlinLanguageInjector` using Registry to enable annotation injections"
This reverts commit c16a1d598c2bacc849dd16fed974ccdbf8b80754.
Revert "`KotlinLanguageInjector#injectInAnnotationCall` optimization: using `PsiClassNamePatternCondition` to avoid calling `getResolvedCall`"
This reverts commit f9eaaeab61b1dd50de9341846e129b58eb47f247.
Revert "`KotlinLanguageInjector` can inject into files modified for autocompletion"
This reverts commit 7212b22b083023201700696d775355051321b120.
Revert "`KotlinLanguageInjector` understands patterns-injections into Java annotations"
This reverts commit 45847b515bdfd27cfa5d23ff8b9147054ffa6f60.
Generate continuation type as kotlin.coroutines.Continuaion. This code will
fail at runtime since there is no stdlib backing this change yet.
However, in order to generate compatible stdlib we need a compiler, which
generates continuation type as kotlin.coroutines.Continuation.
Thus, firstly we support the change in the compiler, make it bootstrap
compiler and only then change stdlib and tests accordingly.
#KT-23362
For some reason there were ~1000 tests that were spontaneously
falling (~20%) because they couldn't find some class. It was mostly
Java classes.
Those failures started after cff88a3f8b.
There were group of commits about notifications right before it:
b4fb0e0305b77a0caa83d34edac3253b7d8e082b..1be33b91fa85e50f5048dc5a12604debfa3c19e8
#KT-23399 Fixed
When plugins DSL is used, there is no need to
manually generate typesafe accessors for extensions and
conventions (by running `./gradlew kotlinDslAccessorsSnapshot`).
Fix KT-22205 and https://issuetracker.google.com/issues/71556313
Hitting breakpoints in Kotlin JUnit test with an Android Gradle
project sometimes(*) does not work in Android Studio 3.1 beta.
(*) The issue is related to various threads running concurrently
with "dumb" mode background code, so the issue reproduces only
on certain configurations.
In a nutshell, the issue is as follows
* On one hand, gradle build finishes, fires an event ("buildFinished")
that is processed "later" and that causes the IDE to enter "dumb" mode
for a shot amount of time (about 300-500 msec on a somewhat up to date
multi-core computer).
* On the other hand, once the JVM of the debuggee is started, breakpoints
need to be resolved (on the debugger thread, through a call to
com.intellij.debugger.engine.CompoundPositionManager.createPrepareRequests.
This code calls into the "KotlinPositionManager.createPrepareRequests",
which in turns calls into "PerFileAnalysisCache.analyze". That method
returns "AnalysisResult.EMPTY" is the project is in dumb mode.
This return value prevents callers from successfully resolving
the source location into a breakpoint.
Given that the 2 code paths above execute on separate threads without
explicit synchronization, the "failed to resolve breakpoint" issue
occurs sporadically, to the point it happens 100% of the time on
certain configuration.
The fix is so wrap the kotlin breakpoint resolution code inside
a "runReadActionInSmartMode" so that the debugger thread "waits"
for "dumb" mode to terminates before trying to resolve breakpoint
locations.
#KT-22205 Fixed
Nikolay Krasko