With the first method, I'm not sure how to refer to the AnalyzerTest class defined in lit.cfg from lit.local.cfg. It doesn't seem to be in scope, so unless I store an instantiation in the config object, I don't think it's accessible.

With the first method, I'm not sure how to refer to the AnalyzerTest class defined in lit.cfg from lit.local.cfg. It doesn't seem to be in scope, so unless I store an instantiation in the config object, I don't think it's accessible.

Rather than creating and storing an instance of AnalyzerTest in lit.cfg you could store the class itself (that is, an instance of the metatype) and then instantiate it using that when needed in lit.local.cfg. This would avoid creating an long-held, global instance of AnalyzerTest when running other tests.

This looks good to me, although I would prefer if the definition of the AnalyzerTest class were moved to the bottom of the lit.cfg file. The other configuration and substitutions are far more important to the rest of clang -- people shouldn't have to scan through analyzer-specific stuff to get to configuration of broad relevance.

I also think you may end up needing to conditionalize setting config.analyzer_format to only occur on non-win32 -- but you can commit and see if it triggers the bots.