Page MenuHomePhabricator

[analyzer] NFC: Move path diagnostic consumer implementations to libAnalysis.
Needs ReviewPublic

Authored by NoQ on Sep 10 2019, 4:59 PM.



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 :)

Diff Detail

Event Timeline

NoQ created this revision.Sep 10 2019, 4:59 PM
Herald added a project: Restricted Project. · View Herald TranscriptSep 10 2019, 4:59 PM
gribozavr requested changes to this revision.Sep 11 2019, 6:04 AM
gribozavr added inline comments.

Does this code declare e.g., createPlistDiagnosticConsumer? That function is defined in libStaticAnalyzer. Declaring it libAnalysis is not appropriate, and effectively introduces a layering violation. Users who link against libAnalysis will get link errors if they don't link against libStaticAnalyzer.

This revision now requires changes to proceed.Sep 11 2019, 6:04 AM
NoQ marked an inline comment as done.Sep 11 2019, 11:23 AM
NoQ added inline comments.

Oh crap, i forgot to move them.

NoQ added a comment.Sep 11 2019, 11:53 AM

Hmm, does anybody want me to write an example tool that emits path diagnostics but doesn't link to libStaticAnalyzer*?

NoQ updated this revision to Diff 219829.Sep 11 2019, 4:19 PM

Unforget to actually move the consumer implementations to libAnalysis, not just their headers.

Casually rename ClangDiagPathDiagConsumer to TextDiagnostics according to the local naming tradition.

gribozavr added inline comments.Sep 12 2019, 2:33 AM

80 columns?


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.


Passing it by value would have made it less subtle, and probably as efficient.



Or even better, "TextPathDiagnosticsConsumer".

Same for the file name. Same for other files that define diagnostics consumers.

Clarity is really important here. Very few places in the code will mention this type by name, however, it is really important to distinguish this diagnostics infrastructure from the rest of Clang's diagnostics.

I'm also starting to wonder whether this diagnostics infrastructure should be in its own library, not in libAnalysis -- what do you think?