DisableErrorsInGeneratedCode #808
Comments
|
In this specific case, I've suggested that the Immutables.org code generator could emit |
|
FYI now that #599 has landed you can probably achieve this by excluding the paths to the generated code |
and some code changes now required by enabling a few extra checks which in the first round I could not enable because of un-fixable violations in Immutables.org generated code (which could possibly have affected YANG generated code as well later) With with the new XepExcludedPaths, see google/error-prone#821 (instead of google/error-prone#808), we can ignore /target/ so that's not a problem, anymore. The disabled StaticOrDefaultInterfaceMethod is because I've hit it during the build of caches/ but learnt its very Android specific, we don't care, see http://errorprone.info/bugpattern/StaticOrDefaultInterfaceMethod The added FutureReturnValueIgnored is GREAT. Change Log on https://groups.google.com/forum/#!msg/error-prone-announce/-ExdzeDOURY/7cQqwSezCQAJ Change-Id: I05d5497626240d1a30cc54ee3014f1dbe367fcb5 Signed-off-by: Michael Vorburger <[email protected]>
|
I now use XepExcludedPaths to achieve what I originally filed this issue for; just using like:
So at least from my side this issue could just be closed now, there's no "need" for this, actually. |
|
I mean, I'm using -XepExlcludedPaths too, but I also kind of like the idea of ignoring things based on annotation. perhaps even just excluding generated code by default because this is a tool to audit my team's code not generated, and not libraries. |
|
This can be closed now? |
and some code changes now required by enabling a few extra checks which in the first round I could not enable because of un-fixable violations in Immutables.org generated code (which could possibly have affected YANG generated code as well later) With with the new XepExcludedPaths, see google/error-prone#821 (instead of google/error-prone#808), we can ignore /target/ so that's not a problem, anymore. The disabled StaticOrDefaultInterfaceMethod is because I've hit it during the build of caches/ but learnt its very Android specific, we don't care, see http://errorprone.info/bugpattern/StaticOrDefaultInterfaceMethod The added FutureReturnValueIgnored is GREAT. Change Log on https://groups.google.com/forum/#!msg/error-prone-announce/-ExdzeDOURY/7cQqwSezCQAJ Change-Id: I05d5497626240d1a30cc54ee3014f1dbe367fcb5 Signed-off-by: Michael Vorburger <[email protected]>
Would you consider adding a
DisableErrorsInGeneratedCodeoption?As its name implies, it would, just like it's existing inspiration
DisableWarningsInGeneratedCode, prevent errors from being raised on anything annotated with @Generated.I'm expecting you 😇 to reply and close this as you "NEVER!", because "why would anyone possibly want to ignore errors even in generated code?!", but here's the rationale:
Some of error-prone's (great!) checks are not necessarily flagging clear errors only. For example,
Varis more of a best practice style which can help prevent errors - but a violation of it is not an error. I really likeVarthough, and have cleaned up an existing code base to that style (because I now have one small reason less to adopt Kotlin and Xtend which have this same concept), and would now like to enforce it to fail builds running on Gerrit code review if my colleagures re-introduce unnecessary uglyfinal.But I cannot use e.g.
-Xep:Var:ERRORbecause my project uses a code generator which is not (yet) peperring the @var annotation over it's generated code - so I'm stuck. Of course one can try to get that code generator to comply - but, generally speaking, that is not realistic - nor neccesary.The text was updated successfully, but these errors were encountered: