We're finally more or less ready to allow users outside of the Static Analyzer to take advantage of path diagnostic consumers for emitting their warnings in different formats. I didn't really try to do that in practice, but most of the necessary APIs should be at least available now.
I'm not planning to convert Clang-Tidy to use these APIs directly because i understand that they're more complicated than Clang-Tidy really needs them to be. I'll either simplify these APIs (if they indeed can be simplified) or (more likely) introduce a convenient wrapper for easily building path diagnostics.
I'm not sure about renaming these classes to get rid of the "Path" prefix. These diagnostics aren't necessarily displaying the path (and they never did), but they're flexible enough for displaying paths and that's still the primary difference between our path diagnostics and ordinary diagnostics. Also if we just call them "Diagnostics" it'll be too generic and hard to distinguish from the Clang diagnostic engine. Suggestions are welcome :)
Maybe not quite an appropriate comment for this patch, but I just realized that this factory function returns void, which confused me -- where does the new consumer go? Only after reading an implementation of one of these functions I understood that they add the new consumer to C, which is a vector (whose type is conveniently hidden by a typedef -- why?)
I'd suggest to make these factories more like factories, and make them return a unique_ptr that the caller can put wherever they need. Of course, in a separate patch.
I'd also suggest to remove the PathDiagnosticConsumers typedef altogether. It is used just a couple of times in the code, and obfuscates code more than it helps.