clang-analyzer.llvm.org/available_checks.html is still "slated to contain a list of the current checks"

[Quuxplusone]

Bugzilla Link	PR9753
Status	NEW
Importance	P normal
Reported by	Flash Sheridan (flash@pobox.com)
Reported on	2011-04-19 15:31:58 -0700
Last modified on	2012-04-11 11:51:53 -0700
Version	unspecified
Hardware	All All
CC	flash@pobox.com, ganna@apple.com, kremenek@apple.com, llvm-bugs@lists.llvm.org
Fixed by commit(s)
Attachments
Blocks
Blocked by
See also

The analyzer "Available Checks" web page (http://clang-
analyzer.llvm.org/available_checks.html) still says "This page is slated to
contain a list of the current checks the analyzer performs along with some self-
contained code examples. In the meantime…," rather than listing the available
checkers.  The Wayback Machine archive doesn't have the page (perhaps because
of a now-deleted clang-analyzer.llvm.org/robots.txt file), but I believe the
page has been slated to contain the checkers for quite some time.

The list of checker is quite important for prospective users of a static
analysis tool.  (Perhaps too much so; I've seen someone choose a tool based
primarily on the number of checkers it had.)  Cp. Klocwork's list, which is now
public:
http://www.klocwork.com/products/documentation/current/Detected_C_and_C%2B%2B_Issues

[Quuxplusone]

It would help in the interim to add a link to the list of checkers and help
text in the source,
 <https://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Checkers/Checkers.td?view=co>.

[Quuxplusone]

This was fixed in change 143788 the day after I filed this. cfe/trunk/www/analyzer/available_checks.html doesn’t seem to be updated as often as cfe/trunk/lib/StaticAnalyzer/Checkers/Checkers.td, but that may be a conscious decision, in which case I recommend closing this.

[Quuxplusone]

No, I think we should still provide real documentation for all the checkers.

[Quuxplusone]

Ideally, we would have a script that extracts all non-experimental checkers with short documentation from the Checkers.td. Further, we could make each checker name a link that provides additional (manually written documentation).

However, this still does not solve the issue of finding out what each analyzer warning means (I don't think that we currently associate warnings with checker names).