<div dir="auto">Too bad I cant edit mails.<div dir="auto"><br></div><div dir="auto">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).</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 26 Oct 2018 20:58, "Kristóf Umann" <<a href="mailto:dkszelethus@gmail.com">dkszelethus@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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/pipermai<wbr>l/cfe-dev/2018-October/059664.<wbr>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##<wbr>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>
</blockquote></div></div>