[cfe-dev] [analyzer] Refactoring AnalyzerOptions
Kristóf Umann via cfe-dev
cfe-dev at lists.llvm.org
Fri Oct 26 15:17:26 PDT 2018
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:
> 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:
> 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!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-dev