<div dir="auto"><div dir="ltr"><div dir="ltr">Hi!<div><br></div><div>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:</div><div><a href="http://lists.llvm.org/pipermail/cfe-dev/2018-October/059664.html" target="_blank">http://lists.llvm.org/<wbr>pipermail/cfe-dev/2018-<wbr>October/059664.html</a><br></div><div><br></div><div>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</div><div dir="auto">* 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.</div><div dir="auto">* 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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">Thanks to everyone who already took the time to help me with this effort!</div><div dir="auto"><br></div><div dir="auto">Cheers,</div><div dir="auto">Kristóf</div></div></div></div>