When multiple expect declarations are in the same file,
and some of them already have actual declarations for this platform,
then "Create actual fix" put other declarations into the same file
with existing actual declarations
So #KT-17058 Fixed
So #KT-21082 Fixed
Element in constructor can be invalidated when dumb mode begins/ends.
Working with invalid elements can produce nodes without icons and bad
presentation.
#KT-22631 Fixed
This fixes an exception from duplicateJvmSignature reporter
Fixes "QuickFixTestGenerated$Override.testDontOfferToImplementMembersForExpectedClass" on teamcity
Otherwise it's difficult to use a newly added API annotated with
RequireKotlin with the latest, not yet released, version.
For example, suppose there's a new function added in kotlin-stdlib,
since Kotlin 1.3, which requires 1.3 (Kotlin < 1.3 is supposed to report
an error on usages):
@SinceKotlin("1.3")
@RequireKotlin("1.3", COMPILER_VERSION, message = ...)
fun foo() {}
Until Kotlin 1.3 is released, the latest available compiler in Maven has
the version 1.3-SNAPSHOT, which is _less_ than 1.3 according to Maven
rules which are used in getDeprecationByVersionRequirement. Therefore,
errors will be reported on usages of foo, and there's no Kotlin compiler
version which can be used to verify if the function works correctly,
which is inconvenient.
Since SNAPSHOT versions are effectively "pre-release" in a way, it's OK
for them to skip reporting these diagnostics
* Generate missing IR parameter declarations in external stubs
* Use origin = FAKE_OVERRIDE in external IR stubs for fake overrides
* Set .parent in external IR stubs
* Set .parent in IR generated by some utility methods
Property accessor that overrides a non-default property accessor with
visibility different from the property visibility was incorrectly
considered "default". Corresponding metadata was written incorrectly,
and 'internal' setter call caused NSME
#KT-23044 Fixed Target versions 1.2.40
Pill is a Gradle-to-JPS model generator for compiler + compiler plugins + IDE project parts.
The generated project model does not know anything about Gradle and is fully operable using only JPS.
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
Android studio doesn't have this bundled module, so this should
prevent installing plugins for Intellij to AS.
This patch should be reverted in AS branches.
Mikhail Glukhikh