Fixed
Status Update
Comments
mc...@snapchat.com <mc...@snapchat.com> #2
I am also on Catalina if it helps.
ze...@google.com <ze...@google.com> #3
I'm also affected but I'm on Windows10. can confirm it on version 4.0 Canary 9
ze...@google.com <ze...@google.com> #4
Happening on junit tests for me as well.
Android Studio 3.6 RC 1
Build #AI-192.7142.36.36.6071332, built on December 13, 2019
Runtime version: 1.8.0_212-release-1586-b4-5784211 x86_64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
macOS 10.15.2
GC: ParNew, ConcurrentMarkSweep
Memory: 1237M
Cores: 16
Registry: ide.new.welcome.screen.force=true, ide.tooltip.initialDelay=600
Non-Bundled Plugins: IdeaVIM, org.jetbrains.kotlin, com.squareup.sqldelight
Android Studio 3.6 RC 1
Build #AI-192.7142.36.36.6071332, built on December 13, 2019
Runtime version: 1.8.0_212-release-1586-b4-5784211 x86_64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
macOS 10.15.2
GC: ParNew, ConcurrentMarkSweep
Memory: 1237M
Cores: 16
Registry: ide.new.welcome.screen.force=true, ide.tooltip.initialDelay=600
Non-Bundled Plugins: IdeaVIM, org.jetbrains.kotlin, com.squareup.sqldelight
ch...@google.com <ch...@google.com> #5
I'm not yet able to repro this using MvRx project.
Any additional info any of you have to help us repro this would be useful. Such as:
- Is this happening to Java as well as Kotlin tests?
- How did you start the test run exactly? Through clicking the run button at the top bar, or the run button in the gutter next to the test class/method name, or through context menu in the project view?
- Please attach idea.log of when this reproes for you.
Thanks!
Any additional info any of you have to help us repro this would be useful. Such as:
- Is this happening to Java as well as Kotlin tests?
- How did you start the test run exactly? Through clicking the run button at the top bar, or the run button in the gutter next to the test class/method name, or through context menu in the project view?
- Please attach idea.log of when this reproes for you.
Thanks!
ap...@google.com <ap...@google.com> #6
1) I ran StateStoreTest by clicking the arrow next to the class name. Tests passed
2) I changed the expected value for the first assert in testSubscribeNotCalledForNoop from 1 to 2
3) I reran the tests with control + r. Tests passed
4) I reran them again and they correctly failed (because I changed the assert)
I also ran YourKit. Out of the last 2 runs, the 2nd to last ran with out of date sources and incorrectly passed. The last run incorrectly failed.
2) I changed the expected value for the first assert in testSubscribeNotCalledForNoop from 1 to 2
3) I reran the tests with control + r. Tests passed
4) I reran them again and they correctly failed (because I changed the assert)
I also ran YourKit. Out of the last 2 runs, the 2nd to last ran with out of date sources and incorrectly passed. The last run incorrectly failed.
mc...@snapchat.com <mc...@snapchat.com> #7
Thanks, I'm able to repro this now.
ap...@google.com <ap...@google.com> #8
Any update or workaround here? It's extremely error prone to work when you don't know what version of the source Android Studio is using.
ap...@google.com <ap...@google.com> #9
This seems to be an issue where the Gradle plugin does not see up to date sources, maybe due to VFS freshness. Jerome, anyone in Build team can help take a look?
ch...@google.com <ch...@google.com> #10
The issue seems to be that the IDE is not saving files to disc. After changing assert (expecting it to fail), build output contains:
"> Task :mvrx:compileDebugUnitTestSources UP-TO-DATE"
This means that the file state did not change on disk (AGP&Gradle do not use Intellij VFS).
"> Task :mvrx:compileDebugUnitTestSources UP-TO-DATE"
This means that the file state did not change on disk (AGP&Gradle do not use Intellij VFS).
ap...@google.com <ap...@google.com> #11
The issue is in GradleBuildInvoker.executeTasks(Request) method. Because "request.isWaitForCompletion()" is true and the current thread is not a dispatch thread, we invoke "executor.queueAndWaitForCompletion()" without invoking "myDocumentManager.saveAllDocuments()" first. This means that we do not flush editor state to disc before Gradle is invoked. Consequently, build is using stale files.
Raluca, should we always invoke "myDocumentManager.saveAllDocuments()"?
Raluca, should we always invoke "myDocumentManager.saveAllDocuments()"?
ap...@google.com <ap...@google.com> #12
I think so, yes. It used to be the case, before Change I3b29b1a3bfc. And also, looking at IntelliJ's own handling of Gradle-based projects (ExternalSystemUtil), their incantation before calling Gradle is:
TransactionGuard.getInstance().assertWriteSafeContext(ModalityState.defaultModalityState());
ApplicationManager.getApplication().invokeAndWait(FileDocumentManager.getInstance()::saveAllDocuments);
ch...@google.com <ch...@google.com> #13
Thanks for confirming that. Bradley can take care of fixing this.
ap...@google.com <ap...@google.com> #14
Thanks for fixing this! Will it be cherry-picked into 4.0?
Description
Proguard rules:
-keepclassmembers,allowobfuscation @com.example.reflectionerror.JobId class * {
<init>(...);
}
Sample Application:
package com.example.reflectionerror
import android.app.Application
@Target(AnnotationTarget.ANNOTATION_CLASS, AnnotationTarget.CLASS)
@Retention(AnnotationRetention.RUNTIME)
annotation class JobId
@JobId
class Job
class App: Application() {
override fun onCreate() {
super.onCreate()
try {
Job::class.java.getConstructor()
} catch (e: NoSuchMethodException) {
throw IllegalStateException("No constructor")
}
}
}