-
Notifications
You must be signed in to change notification settings - Fork 742
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
Support @SuppressWarnings("all") #329
Comments
Workaround if you don't need "modify-by-copy" for your value types: disable it entirely. // Disable modify-by-copy generation by Immutables.org
// to avoid StringEquality warnings from Error Prone
@Value.Style(
defaults = @Value.Immutable(copy = false)
)
package com.example;
import org.immutables.value.Value; Of course using the Alternatively, maybe Error Prone could have an option to ignore warnings for code generated by annotation processors? (ignoring errors might not be a good idea) BTW, apparently, at least Eclipse and IntelliJ IDEA support |
Sorry for the slow reply. We don't want to support @SuppressWarnings("all") because we want people to be precise in suppressing warnings, and to explain why it's safe to do so. For the code generator case, what if we turned off warnings for files with an @generated annotation? That would match what we do internally -- we don't show warnings on generated code, but we do issue errors. |
👍 I wonder if that couldn't be triggered on any generated class (you have access to the information in the |
I'm finally getting around to implementing this. @tbroyer, any ideas on how to use the I guess we could assume that |
If the code generator includes it in the produced source code, you could look for the |
Yep, that's the same My plan is to add a flag that will suppress warnings in @generated code. Any fancier ways of recognizing annotation processor generated code would be in addition to recognizing @generated, not a replacement. |
AFAIK, there are no standard ways to find out if specific file was generated by annotation processing API. Javac specific classes could possibly keep track of this, but then, processing rounds and different annotation processors come into play, and also annotation processing is not the only mean to generate code. Fancier ways to detect generated code could possibly cover only fraction of such cases and, in result, have low power-to-weight ratio. So, I think, relying on the presence |
@cushon I was initially thinking about intercepting calls to Looking at @elucash Not all generators include a |
@tbroyer thanks for the pointers. Getting the information out of the filer looks doable, but I think it ends up requiring hacky reflection. I'd prefer to avoid that. I implemented the version that just checks for |
@cushon Thanks. Now eagerly awaiting the next error-prone release ;-) |
The last release is only a week old, so it could be a few weeks before the next one. You could try it out with the snapshot releases, though: https://oss.sonatype.org/content/repositories/snapshots/com/google/errorprone/ |
Hmm, 2.0.5-SNAPSHOT doesn't work for me (and this is version 2.0.5-20150630.195032-3, which is what the Travis build deployed). Repro-case:
repositories { maven { url 'https://oss.sonatype.org/content/repositories/snapshots/' } }
configurations.errorprone {
resolutionStrategy.force 'com.google.errorprone:error_prone_core:2.0.5-SNAPSHOT'
} Then run
|
I should have mentioned that it's behind a flag. Does passing |
Indeed works much better ;-) |
hmm... errorprone like this
getting this failure though on an immutables generated class.
I'd guess it's because it's an error and not a warning? I've set it to error because I want CI failures, but I also don't want it to fail on generated code. |
Summary: This fixes OptionalEquality bug pattern flagged by error prone. [OptionalEquality] Comparison using reference equality instead of value equality if (this.stubBinaryPath == value) return this; ^ (see http://errorprone.info/bugpattern/OptionalEquality) Did you mean 'if (Objects.equals(this.stubBinaryPath, value)) return this;' or 'if (this.stubBinaryPath.equals(value)) return this;'? Test Plan: CI. References: google/error-prone#329 google/error-prone#505 immutables/immutables#502 immutables/immutables#519
The one suppression is already adequately explained, and Error Prone intentionally doesn't respect @SuppressWarnings("all"): google/error-prone#329 Change-Id: I76f21fff3d727c3c49aa83d6af54145ab45717e5
Immutables.org (similar to AutoValue) uses
@SuppressWarnings("all")
on the files they generate.Their generated withers use reference equality as an optimization (returning
this
–the current immutable object– rather than a new immutable object that would be strictly identical): https://github.com/immutables/immutables/blob/d8075fc66be685696bb2ccba36085b2437e11545/value-processor/src/org/immutables/value/processor/Immutables.generator#L1391-L1400This causes a lot of warnings during compilation (only for strings though):
because Error Prone doesn't recognize
@SuppressWarnings("all")
.(note: if you believe it's a really bad practice to suppress all warnings even in code generated by an annotation processor –i.e. code you don't control–, then I'll open an issue on Immutables.org so they emit
@SuppressionWarnings("StringEquality")
instead)/cc @elucash
The text was updated successfully, but these errors were encountered: