[cfe-dev] [analyzer] The use of tblgen in the analyzer

[Artem Dergachev via cfe-dev]

This is why i say that "i found a bug by looking at this report" is not 
a valid definition of a true positive. You can find bug in *any* code if 
you stare at it long enough.

I've no idea how DescFile can be useful. It might be that the old 
autotools-based build system was using it somehow. Finding file by 
checker name is a rare task that can usually be accomplished with grep, 
so no need to keep it for humans. Feel free to squash.

Our -analyzer-config is indeed pretty chaotic. I heard that it was 
designed for just one purpose: to not fail with an error when a flag is 
not available, which is good for backward and/or forward compatibility.

I guess maintaining a current list of flags will still be good, 
especially with longer descriptions, so you can try to do this. I highly 
favor .def files (that can be #included directly, eg. Analyses.def) over 
TableGen because TableGen code looked very hard to understand last time 
i tried to work with it.

Analyzer config flags are also very different, which suggests a UI 
distinction:
- A lot of them define "alpha" branches, so we shouldn't suggest users 
to use them unless they're developing the respective feature.
- Some define branches that were turned on by default so long ago that 
nobody remembers them, so i guess they can be removed (eg., 
c++-template-inlining).
- Some are thresholds or "temporary" hacks that are good to have as an 
option so that it was easy to experiment with them (adjust thresholds or 
remove hacks).
- Some are useful for debugging (eg., prune-paths).
- Some are actually important to maintain (eg., elide-constructors, 
because lack of copy elision is a valid behavior until C++17, and it's 
likely that some code is compiled without copy elision, and they may 
want to tell the Analyzer to match their behavior).

Supporting checker options (that are also passed as weird 
-analyzer-config flags) is going to be a separate challenge.


On 10/7/18 11:26 AM, Kristóf Umann via cfe-dev wrote:
> Hi!
>
> I have two questions about this topic.
>
> 1. Checker registration:
>
> I am in the process of updating clang-analyzer.llvm.org 
> <http://clang-analyzer.llvm.org>, and as I went through the checkers 
> that were missing, I encountered this:
>
> def NonnullGlobalConstantsChecker: Checker<"NonnilStringConstants">,
> HelpText<"Assume that const string-like globals are non-null">,
> DescFile<"NonilStringConstantsChecker.cpp">;
> What is particularly interesting here (other than the mismatched 
> names), is that NonilStringConstantsChecker.cpp doesn't exist, in fact 
> it never did. To my greatest surprise, DescFile isn't used anywhere!
> #define CHECKER(FULLNAME,CLASS,DESCFILE,HELPTEXT,GROUPINDEX,HIDDEN) \ 
> registry.addChecker(register##CLASS, FULLNAME, HELPTEXT);
> So, is there a point in keeping DescFile entries?
> 2. Use tblgen for AnalyzerOptions:
> I dislike that I need to look at source code, or doxygen at best to 
> know what kind -analyzer-config options are available. Would it be a 
> good idea for me to refactor it with tblgen?
> Cheers,
> Kristóf
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20181008/c98012dd/attachment.html>