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

[Kristóf Umann via cfe-dev]

Thanks for the clarification! I think I'll refactor the whole thing as you
suggested, it's been bothering me for too long. I'll move the flags to a
.def file and attempt to emit warnings on invalid input.

Artem Dergachev <noqnoqneo at gmail.com> ezt írta (időpont: 2018. okt. 9., K,
3:24):

> 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, 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 listcfe-dev at lists.llvm.orghttp://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/20181012/2802dbe5/attachment.html>