[cfe-dev] [analyzer] Refactoring AnalyzerOptions

[Kristóf Umann via cfe-dev]

Too bad I cant edit mails.

Where I talked about extracting all isn't easily accessable fields and
related methods to CheckerManagerData, I actually meant *easily* accessible
(since some checkers actually need to access LangOptions, as well as
AnalyerOptions, both avaible when other similar -help options are handled).

On 26 Oct 2018 20:58, "Kristóf Umann" <dkszelethus at gmail.com> wrote:

> Hi!
>
> We did have a thread about this but with a very misleading title, so
> here's a link to that, and I'll get into this mail:
> http://lists.llvm.org/pipermail/cfe-dev/2018-October/059664.html
>
> AnalyzerOptions shouldn't be mutable once fully initialized (which should
> be achieveble by the time the actual analysis begins), and the greatest
> enemies of this idea are checker options, because
> * we can either forget about collecting all checker options and possibly
> diagnose them, and let checkers use AnalyzerOptions as a sort of set of
> user supplied options. This is the current state of things, and should my
> non-checker option refactoring effort go through, AnalyzerOptions can be
> made const straight away.
> * we could supply a mutable AnalyzerOptions object to the checkers when
> registering, let them register and evaluate their options, and make it
> immutable for the rest of the analysis.
>
> I'm highly in favour of the second option, but it's a non-trivial issue,
> mostly because of external plugins, which is why I'm looking for some
> feedback on my ideas.
>
> In order to register (and, more importantly, initialize) checkers, one
> needs to have access to a CheckerManager object, which isn't trivial to
> create, which makes it impossible to implement a help flag (like
> -analyzer-checker-help or the proposed -analyzer-config-help). I'm
> proposing two possible solutions.
>
> 1. Extract everything that isn't easily accessible to a new
> CheckerManagerData class, make CheckerManager only responsible for
> interacting (but not registering) checkers. I've got a fork on which I
> managed to get this working, but I disliked this approach, and went on to
> find a better solution.
>
> 2. Force checkers to properly register their options in a new,
> registerOptionsFor##CHECKERNAME function, which would take
> AnalyzerOptions as a parameter, alongside register##CHECKERNAME. This would
> add one more complication to the already very-not-trivial registering
> process, but could also be autogenerated using tblgen.
>
> It's clear to me that the second option is superior to the second, but
> going forward with either is a lot of work, so I'm looking for feedback.
>
> Thanks to everyone who already took the time to help me with this effort!
>
> Cheers,
> Kristóf
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20181027/f0888f39/attachment.html>