[cfe-dev] [RFC][clang-tidy] Register warnings as check aliases

[Daniel Marjamäki via cfe-dev]

Hello!

This sounds useful for those that wants to check CERT compliance.

However if I just run clang-tidy as a complement to get extra checks .. then I don't want that clang compiler warnings are enabled and renamed "behind my back". Do you think we can avoid that?

Many static analyzer checkers has partial coverage of CERT rules also. For instance out-of-bounds, dereferencing null pointers, etc. I assume you would only alias checks that has full coverage?

Imho it would be good to someday have MISRA, JSF, .. checks also. And I assume there is some overlap. so same warning could be aliased by both cert-* and misra-* etc.

Best regards,
Daniel Marjamäki

..................................................................................................................
Daniel Marjamäki Senior Engineer
Evidente ES East AB  Warfvinges väg 34  SE-112 51 Stockholm  Sweden

Mobile:                 +46 (0)709 12 42 62
E-mail:                 Daniel.Marjamaki at evidente.se

www.evidente.se

________________________________________
Från: cfe-dev [cfe-dev-bounces at lists.llvm.org] för Gábor Horváth via cfe-dev [cfe-dev at lists.llvm.org]
Skickat: den 28 september 2016 09:44
Till: Clang Dev; Alexander Kornienko; Aaron Ballman
Ämne: [cfe-dev] [RFC][clang-tidy] Register warnings as check aliases

Hi!

I would like to propose that it should be possible to register compiler warnings as clang-tidy check aliases.

As a motivating example, there is a CERT C++ secure coding rule: ERR54-CPP [1]

This rule is covered by the clang warning: -Wexceptions

So turning on this check in clang tidy would have two effects: turning on -Wexceptions and display the result of -Wexceptions as ERR54-CPP hits.

In my opinion aliases like this would be a great usability improvement:
 - it would be easier to check the code against some coding guidelines.
 - it would be easier to check what rules are already covered.
 - it would be easier to find uncovered rules to implement.

What do you think? Would you support a feature like that?

Regards,
Gabor

[1]: https://www.securecoding.cert.org/confluence/display/cplusplus/ERR54-CPP.+Catch+handlers+should+order+their+parameter+types+from+most+derived+to+least+derived