[cfe-dev] Help naming library with interface to SARIF Document writing

[Aaron Ballman via cfe-dev]

On Wed, Jun 30, 2021 at 5:31 PM Vaibhav Yenamandra (BLOOMBERG/ 919 3RD
A) via cfe-dev <cfe-dev at lists.llvm.org> wrote:
>
> Hello Everyone,
>
> I've been working on adding support for emitting SARIF from clang via -fdiagnostics-format=sarif (rfc: https://lists.llvm.org/pipermail/cfe-dev/2021-March/067907.html), and need to decide on the name / location of a new library I will add to clang in the process, and would like to hear community input.

That's great, thank you for working on this!

> The goal of this library would be provide a `clang::SarifDocumentWriter` and related types that represent SARIF data. For now it depends on clang specific types such as `clang::SourceManager`, `clang::SourceLocation`. Also if there are any guides to conventions withing LLVM/cfe-dev surrounding namespaces, I'd be happy to use them to come up with something as well :)

I think it generally makes sense that this functionality will be used
mostly from Clang, but at the same time, SARIF is about exchanging any
kind of analysis results and so there's a small part of me that
wonders whether we'd want this to live as an LLVM support library
rather than a Clang support library? The file format itself is in JSON
and the concepts expressed by the format are generally independent of
frontend vs backend. However, I think that Clang is by far the more
common use case, so I'm fine designing something exclusively for
Clang's use if that's the better approach.

Depending on where the library lives (LLVM vs Clang) will help with
the namespace. We typically aren't super namespace-heavy, so putting
the functionality within the llvm or clang namespace is likely
sufficient. If there's concern about naming conflicts from that, you
could go with llvm::sarif or clang::sarif.

> As for the name for the Sarif library: I am thinking of calling it "clang/Support/Sarif.h" within "clangSupport" (akin to llvm/Support/JSON.h), are there any objections to this / other names or locations I can place this code in?

I don't think we really need a clangSupport library for this if it's
going to be tied tightly to Clang's interfaces like SourceManager. In
that case, I'd imagine it'd live next to the rest of the diagnostics
functionality in clangBasic -- that's at a good layer for sharing with
other parts of the project like the static analyzer. However, if you
do think LLVM is a better place for it to live, I think llvmSupport
would make sense.

~Aaron

> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev