[PATCH] D109701: [clang] Emit SARIF Diagnostics: Create `clang::SarifDocumentWriter` interface

Aaron Ballman via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Tue Oct 19 05:31:45 PDT 2021


aaron.ballman added inline comments.


================
Comment at: clang/include/clang/Basic/Sarif.h:229
+/// used to create an empty shell onto which attributes can be added using the
+/// \c setX(...) methods. The 
+///
----------------
No idea what clang-format wants done here, but there's a stray `The` at the end of the line.


================
Comment at: clang/include/clang/Basic/Sarif.h:95
+//
+/// Since every in clang artifact MUST have a location (there being no nested
+/// artifacts), the creation method \ref SarifArtifact::create requires a
----------------
vaibhav.y wrote:
> aaron.ballman wrote:
> > How do we expect to handle artifact locations that don't correspond directly to a file? For example, the user can specify macros on the command line and those macros could have a diagnostic result associated with them. Can we handle that sort of scenario?
> I hadn't considered `-D` macros. Definitely a valid case to handle. I will respond with more information once I read through the related portions of the SARIF spec. A (sort of hacky?) solution come to mind after a quick glance:
> 
> Setting the artifact URI to: `data:text/plain:<CLI_ARG>` with an offset, and saying that it's role is `"referencedOnCommandLine"`. It seems strange since we need to copy over the command line, instead of referencing it directly. What do you think: https://docs.oasis-open.org/sarif/sarif/v2.1.0/os/sarif-v2.1.0-os.html#_Toc34317617
> 
> Dropping a TODO comment so I can update later.
> 
> `TODO(envp)`
>From my reading of SARIF, I think that sounds plausible. At least, I didn't see anything else that would work.


================
Comment at: clang/lib/Basic/Sarif.cpp:230-232
+  if (!hasRun()) {
+    return;
+  }
----------------
vaibhav.y wrote:
> aaron.ballman wrote:
> > Is there a reason why we don't want to assert instead?
> Creating a document requires ending any ongoing runs, and it is valid to create a document without any runs, so `createDocument()` calls `endRun()`.
> 
> I guess having a flag to mark the status of the document, and only calling `endRun()` if a an active run exists would likely be better. (`hasRun()` seems to have a rather broad responsibility, tracking both the availability & state of the current run)
> 
> I'm thinking of adding a `Closed` flag to the writer (default `true`), which is unset whenever `createRun()` is called, and `endRun()` will set the same flag. That way we only `endRun()` if there is something to end, like so: 
> 
> 1. Constructor makes writer with `Closed = true`
> 2. `createRun()` requires `Closed == true`, and sets it to `false`
> 3. `endRun()` requires `Closed == false`, and sets it to `true`
> 4. `createDocument()` requires `Closed == true`, and will call `endRun()` to ensure that
> 
> What do you think?
I think that makes sense. Adding assertions where appropriate would also help users who misuse the interface catch their issues earlier rather than later.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D109701/new/

https://reviews.llvm.org/D109701



More information about the cfe-commits mailing list