Is there any way to suppress warnings using specific annotation?

[Pavel Baranchikov]

Hello.

I have several places, where I would like to suppress some or all checkstyle warnings, reported tor specifically annotated code.

The first example, is @Generated annotation, set upon the class. During my build script I avoid checking generated sources, but Eclipse still shows me multiple errors when I open the files to look at their contents. This irritates a log.

The secomd example is using @Rule JUnit annotation, which require the field to be public, while VisibilityModifier module forces all the fields to be private. In this case, I whould like to turn off violations reporting for module VisibilityModifier for fields, annotated by @Rule annotation.


My question is the following: is there any suppression mechanism, suitable for my needs? Otherwise, I should code it by myself.

Best regards,
Pavel.

[Roman Ivanov]

Hi Pavel,

https://github.com/checkstyle/checkstyle/issues/289

http://checkstyle.sourceforge.net/config.html#SuppressWarningsFilter

I am not sure if it works properly, let me know if that helps you, if not I could think more about your cases.

I know that Checkstyle have problems in suppression mechanism, we even want to invent flexible suppression instead of line numbers, but it is only plans. Any contribution is appreciated, but should be discussed with us before implementation.

thanks,

Roman Ivanov

​

[Roman Ivanov]

Hi Pavel,

> SuppressWarningsFilter is not exactly what I want, because this should

leam multiple developers to misuse the annotation to avoid style conformance
checks.

yes :), the best way to enforce standard is to not let developer to write suppression easily in code, and allow suppression only in configuration.

> That's why my idea was to crate a similar filter (or to alter

SuppressWarningsFilter) to make it configurable, .....

Idea pretty reasonable, So lets think about that as separate filter. it should be smth similar to SuppressAnnotationFilter or smth like that.

two options: 

- suppressed checks (list of String)

- annotaion (String with full qualified name of annotation )

So here is nuance --- where to stop checking for annotation ? on statement? on method ? on class ? We need to check for annotation up to the root, to work in the same way as SuppressWarning.

Annotations have elements (usually referenced as "parameters")  should we care about them ?

https://docs.oracle.com/javase/7/docs/api/java/lang/annotation/Target.html

@Target(ElementType.ANNOTATION_TYPE)

@Target({ElementType.FIELD, ElementType.METHOD, ElementType.FIELD})

that annotations are different, so suppression by annotation="java.lang.annotation.Target" does not look reasonable, so we need to consider elements too.

Does it make sense ?

thanks,

Roman Ivanov

​

[Pavel Baranchikov]

Hello, Roman,

So here is nuance --- where to stop checking for annotation ? on statement? on method ? on class ? We need to check for annotation up to the root, to work in the same way as SuppressWarning.

Yes, I suggest that all the checkstyle suppressions should be calculated using OR up to the top ANTLR hierarchy (class object).

Annotations have elements (usually referenced as "parameters")  should we care about them ?

https://docs.oracle.com/javase/7/docs/api/java/lang/annotation/Target.html

@Target(ElementType.ANNOTATION_TYPE)

@Target({ElementType.FIELD, ElementType.METHOD, ElementType.FIELD})

that annotations are different, so suppression by annotation="java.lang.annotation.Target" does not look reasonable, so we need to consider elements too.

I think we should not take care about annotation target, as it should be the work of Java compiler to sort wrong syntax out.
I see the simplest way to ignore annotation parameters at all, as I do not see any occasion, where annotation parameters should or should not lead to suppressing warnings from the part of code.

If you insist on analyzing annotation parameters, it should take some additional work:

• how can we configure certain annotation parameters in configuration file?
• I doubt it supports more complex structures that simply holding parameter=value map for each check.
• Parsing complex value using the specific syntax seem not to have adequate development efforts.

I think, we can implement the suppression filter without annotation parameters as the first implementation. After this, we can add parameters procession, if it will be required by any of Checkstyle users.

Best ragards,

Pavel Baranchikov

[Roman Ivanov]

Hi Pavel,

> If you insist on analyzing annotation parameters, it should take some additional work

I do not insist, just curious and question that.

> I think we should not take care about annotation target,

Target was just an first example that I found in internet as annotation with elements (there is not parameters in annotations according to jdk specification).

> I think, we can implement the suppression filter without annotation parameters as the first implementation

Ok, I think that Filter will be in demand.

So, we need to think where we will host new Filter, in checkstyle or sevnu.checkstyle.

in checkstyle - you and we will need to test it extensively before final merge.

in sevnu.checkstyle - we could do less testing and release it and let you test it on your code for a while.

thanks,

Roman Ivanov

​

[Pavel Baranchikov]

Hello, Roman

> So, we need to think where we will host new Filter, in checkstyle or
sevnu.checkstyle. in checkstyle - you and we will need to test it extensively
before final merge. in sevnu.checkstyle - we could do less testing and release
it and let you test it on your code for a while.

I do not object of any of the ways, as my company already uses sevntu-
checkstyle for EnumValueNameCheck check. But I doubt, that any other companies
should use sandbox project sevntu-checkstyle, as they should not even know
about it.

--

Best regards,
Pavel Baranchikov
Thursday 04 December 2014

[Roman Ivanov]

Hi Pavel,

Judging by amounts of massive refactoring we are doing now and going to do in checkstyle during next couple month, please stay in Sevntu project for now.

I think that i will not have enough time to polish and test your filter and i do not want to block you.

Thanks,
Roman Ivanov

[Alex Karnatskyi]

Hello!
Could you tell me please if this filter (suppression of warnings about javadoc absence on methods with specific annotaions) was developed and where can I find it if it was?

Thanks in advance!

[Roman Ivanov]

Hi Alex,

Feature is not done, implementation is incomplete and abandoned 

https://github.com/checkstyle/checkstyle/issues/1340

https://github.com/sevntu-checkstyle/sevntu.checkstyle/pull/368

Feel free to continue ...

--
You received this message because you are subscribed to the Google Groups "checkstyle-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to checkstyle-devel+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.