-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Moe sync 12/05/2016 #407
Moe sync 12/05/2016 #407
Conversation
I think we need to figure out why ExtensionTest is failing with this error: Implicitly compiled files were not subject to annotation processing. But only on Java 7, not on Java 6 nor on Java 8. |
It's failing in openjdk7, but not oraclejdk7 or oraclejdk8... it's bizarre because it's only compiling that one file, and just in that one test. Do you remember why you added Separately, do we care about compiling with jdk7 anymore? Everyone should be using javac8 even if they pass |
The We can certainly discuss no longer compiling with jdk7. Do you want to open an issue for that? I'd like to fix the issue at hand if we can, though. |
Nobody should ever “pass
Those tests are checking for I wonder if those errors aren't false positives / flakes. It'd be interesting to know which class / source file was implicitly compiled. I actually wonder if compile-testing shouldn't default to using an empty source path to prevent those kind of implicit compilation to begin with. |
My inclination is to add "-implicit:class" to the tests, which is supposed to silence that particular warning. I agree that it would be interesting to know what the implicitly-compiled file in question is, but I'm not able to reproduce the failure on my own machine so I don't see a straightforward way to find out. |
FWIW, I couldn't reproduce either [1], so it might be related to the version of Maven being used, or the way the build is done on Travis (building once without tests, then rebuilding with the tests but without cleaning; in my projects, I disabled the first run and just live with the [1] I used Docker to get an OpenJDK 7, as my Ubuntu only has OpenJDK 8:
|
Now, in addition to being able to say immutableListBuilder() for a property of type ImmutableList<T>, you can say fooBuilder() for a property of an arbitrary type that has a builder following certain conventions. In particular, you can do this if the type of foo() is itself an @autovalue class with a builder. API discussion: https://docs.google.com/document/d/1F-mP_pgLVIfaqm2A24Kt-2bkDkAVBQv88vSzAHZ7NOw/edit# (starting on page 5). ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=140584023
… private. This constructor was never documented, and its presence means that we can't know whether @autovalue instances are converted back into builders or not. That in turn means that, currently, if we have `Foo foo()` in the @autovalue class and `FooBuilder fooBuilder()` in the @AutoValue.Builder class, then `Foo` must have a `FooBuilder toBuilder()` method, in case a `Foo` ever needs to be converted back into a `FooBuilder`. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=140958480
…around a compiler warning that causes test failures. See discussion in #407. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=141184041
b073a2e
to
651aa3a
Compare
@eamonnmcmanus LGTY? |
Great, thanks! |
No description provided.