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.
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.
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!
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).
Actually, I already have a fork on which I managed to get this info into Checkers.td (and have come to the same conclusion about tblgen being difficult to manage).
The biggest complication is the existence of external plugins. What are your feelings on the second solution I proposed? Whether I use a .def file or a .td file makes little difference to me at the moment, that’s something I can always change, if I have a lot of free time and more then 3-4 handfuls of hair.