Turbine breaks ASWB IDE sync for projects using Robolectric (android_local_test)

[jongerrish]

Description of the problem / feature request:

Turbine breaks ASWB IDE sync for projects with Robolectric tests.

Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

Using Android Studio w/ Blaze v4.0+ sync a project with an android_local_test rule.

What operating system are you running Bazel on?

Mac

What's the output of bazel info release?

development version

If bazel info release returns "development version" or "(@non-git)", tell us how you built Bazel.

Our internal fork based on v.4.0.0

What's the output of git remote get-url origin ; git rev-parse master ; git rev-parse HEAD ?

git@github.sc-corp.net:Snapchat/bazel.git
2e15fa7e372a3118a09438624494b570e84c44d3
2e15fa7e372a3118a09438624494b570e84c44d3

Have you found anything relevant by searching the web?

I created this issue on the Robolectric tracker:
robolectric/robolectric#6242

Dagger seems to have stumbled on this issue and worked around it by pegging their Bazel version at v3.7.x:
google/dagger@1b5b075

This is the actual Turbine error check that fails:
google/turbine@8bbf4cb

This is the annotation that causes the problem:-
https://github.com/robolectric/robolectric/blob/master/annotations/src/main/java/org/robolectric/annotation/Config.java

I'm unsure why its reporting clinit as the missing attribute however.

Any other information, logs, or outputs that you want to share?

To reproduce from the command line you can just trigger the ASWB IDE aspect, this command is the smallest stripped down command that the IDE issues. Note that intellij-resolve-java is the key output group since this is what triggers Turbine. Note, that it is possible to build and run tests because Turbine isn't invoked for an android_local_test target in these cases. It's the aspect that triggers Turbine.

bazel build --aspects=@intellij_aspect//:intellij_info_bundled.bzl%intellij_info_aspect "--override_repository=intellij_aspect=/Users/jgerrish/Library/Application Support/Google/AndroidStudio4.1/plugins/aswb/aspect" --output_groups=intellij-resolve-java -- //foo/bar/baz:test

[jongerrish]

@cushon - Any idea why Turbine would fail when processing https://github.com/robolectric/robolectric/blob/master/annotations/src/main/java/org/robolectric/annotation/Config.java - Its an interesting annotation (with an implementation and a bunch of complexity) but I'm not sure why Turbine would fail with clinit as a missing attribute. Any insights?

I can work around this in our repo by removing any redundant annotations and the rest migrate to Kotlin whose source files obviously don't trigger Turbine.

[Bencodes]

@jongerrish have you tried testing with this commit pulled into your fork? bef4bbb

[cushon]

Thanks for the heads up, this is a bug in turbine that I was able to reproduce at head, I'm working on a fix

[cushon]

The bug affects any annotation declaration with a class initializer. That's somewhat uncommon, because default values for annotation element have to be compile-time constants, so stuff like int ALL_SDKS = -2; is initialized from the constant pool without needing a <clinit> method. The exception here is Class<? extends Application> DEFAULT_APPLICATION = DefaultApplication.class;, since class literals aren't compile-time constants in the JLS 15.28 sense, so there's <clinit> for that:

  static {};
    descriptor: ()V
    flags: (0x0008) ACC_STATIC
    Code:
      stack=1, locals=0, args_size=0
         0: ldc           #1                  // class org/robolectric/annotation/DefaultApplication
         2: putstatic     #2                  // Field DEFAULT_APPLICATION:Ljava/lang/Class;
         5: return
      LineNumberTable:
        line 39: 0

If you want a work-around, inlining DEFAULT_APPLICATION or moving the declaration into another non-annotation class (like Implementation) should avoid the bug.

[jongerrish]

Amazing! Thanks for the fast turnaround Liam!

[cushon]

The fix was merged in 57672ac

It won't be visible until it makes it into java_tools release. If you're able to do a cherry-pick I'm not sure what the best way to do that for tools is, @comius may have suggestions.

[comius]

Making a java_tools release: bazelbuild/java_tools#45