[cfe-dev] [analyzer] The use of tblgen in the analyzer
Artem Dergachev via cfe-dev
cfe-dev at lists.llvm.org
Fri Oct 19 14:59:23 PDT 2018
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:
>> 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">,
>> 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
>> 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?
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-dev