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

[Artem Dergachev via cfe-dev]

Argyrios, thanks for the archeological insight! I wouldn't have guessed :)

Hmm, what if we make analyzer options verified by default, but have such 
verification disabled by a flag (eg. 
`-analyzer-config-compatibility-mode`) that's enabled by default *by* 
the Clang Driver?

Analyzer GUIs/wrappers usually work through the Driver by appending 
`--analyze` to the build command. It might look like scan-build is an 
exception as it runs `clang -cc1` directly, but before that it anyway 
dumps the default driver flags by running appending `--analyze -###` to 
the (modified) build command. So this might be both safe for 
backward/forward compatibility purposes *and* helpful for developers.


On 10/17/18 12:57 PM, Kristóf Umann via cfe-dev wrote:
> + Dániel Krupp
>
> Another idea I was thinking is
>
> 1. To be able to dump all analyzer configs in a JSON (or yaml, 
> whatever) file, and similarly, be able to read such a config file.
>
> 2. The use of Optional is impactical. We lazily evaluate every option 
> the user supplied only when is asked for. Instead, we could do the 
> evaluation when the cmd line options are parsed, at which point we can 
> also check for wrong input (like whether string options have typos, or 
> flag X won't do a thing when flag Y isn't set) since we have access to 
> a DiagnosticsEngine.
>
> 3. Remove getBooleanOption, getOptionAsString, etc, and only provide 
> general option getters for checkers, in order to support shared lib 
> checkers. This would force anyone who'd like add a flag to actually 
> register it properly. I'm already trying to come up a neat solution to 
> neatly handle checker options.
>
> I've wasted more time on making a typos in config flags than I'd like 
> to admit, so I'm super motivated to make a much stricter version of 
> AnalyzerOptions. While keeping backward compatibility, of course.
>
> Argyrios Kyrtzidis <akyrtzi at gmail.com <mailto:akyrtzi at gmail.com>> ezt 
> írta (időpont: 2018. okt. 13., Szo, 0:45):
>
>
>
>>     On Oct 7, 2018, at 11:26 AM, Kristóf Umann via cfe-dev
>>     <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> 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?
>
>     Just to give some context for ‘DescFile', the intention of this
>     was to point to a file that we could use to add detailed
>     documentation for a checker with a specific format, think of
>     something like extensive doxygen documentation, and a tool would
>     be able to extract such detailed documentation from the source
>     files and render them in another format, like html pages for
>     clang-analyzer.llvm.org <http://clang-analyzer.llvm.org>.
>
>     However, this never materialized and it’s useless now.
>
> Thanks! That actually sounds neat, we had a few conversations in the 
> office about auto-generating the website, like clang-tidy, so I'm not 
> a hurry to remove these just yet.
>
>
>>     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 <mailto:cfe-dev at lists.llvm.org>
>>     http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>     <http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>
>
>
> _______________________________________________
> 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/20181019/4624bb12/attachment.html>