This is an archive of the discontinued LLVM Phabricator instance.

Update to SARIF 11-28
ClosedPublic

Authored by aaron.ballman on Dec 14 2018, 8:26 AM.

Details

Summary

This updates our SARIF support from 10-10 to 11-28. Functional changes include:

  • The run.files property is now an array instead of a mapping.
  • fileLocation objects now have a fileIndex property specifying the array index into run.files.
  • The resource.rules property is now an array instead of a mapping.
  • The result object was given a ruleIndex property that is an index into the resource.rules array.
  • rule objects now have their "id" field filled out in addition to the name field.
  • Updated the schema and spec version numbers to 11-28.

(Note, the SARIF viewer plugins for Visual Studio and VSCode have not caught up to 11-28 yet, but are expected to be updated.)

Diff Detail

Event Timeline

aaron.ballman created this revision.Dec 14 2018, 8:26 AM
aaron.ballman marked an inline comment as done.Dec 14 2018, 9:46 AM
aaron.ballman added inline comments.
lib/StaticAnalyzer/Core/SarifDiagnostics.cpp
218

Ignore this line, it is debugging cruft and will be removed.

NoQ accepted this revision.Dec 14 2018, 12:23 PM

Yup, looks good, and i keep passively cheering for this project to be successful.

lib/StaticAnalyzer/Core/SarifDiagnostics.cpp
129

This sounds like find_if to me.

143

I suspect that the LHS of || implies the RHS of || and is therefore redundant.

289

Aha, ok, so now instead of an alphabetical order we have the order in which reports of the respective checkers are squeezed into the consumer. Which is probably deterministic, so it's fine. I just enjoy talking to myself on phabricator sometimes.

318

I wonder why we didn't mark Diags as const & in this callback.

This revision is now accepted and ready to land.Dec 14 2018, 12:23 PM
aaron.ballman marked 4 inline comments as done.Dec 14 2018, 12:31 PM
aaron.ballman added inline comments.
lib/StaticAnalyzer/Core/SarifDiagnostics.cpp
129

The problem is: we need the Index. It felt a bit weird to have llvm::find_if() (a const operation) also mutating a locally-captured variable. WDYT?

143

Nope, this is needed for a boundary condition. In the case where Files is empty, we don't loop over anything in the range-based for loop, and so Index is zero, which means Index == Files.size(). On the other end of that boundary, if Files is nonempty but FE hasn't been added to it yet, you'll loop over the entire list of Files in the range-based for loop, which also triggers Index == Files.size().

289

Yes, this should be deterministic -- good thought to check!

318

It would be a nice refactoring for someday. :-)

Committed in r349188.

(@NoQ -- if you'd like to see a switch to llvm::find_if(), I'm happy to handle it post-commit.)

NoQ added a comment.Dec 14 2018, 12:45 PM

Sure, np.

lib/StaticAnalyzer/Core/SarifDiagnostics.cpp
129

The way i see it:

auto I = std::find_if(Files.begin(), Files.end(), [&](const json::Value &File {
  if (const json::Object *Obj = File.getAsObject())
    if (const json::Object *FileLoc = Obj->getObject("fileLocation")) {
      Optional<StringRef> URI = FileLoc->getString("uri");
      return URI && URI->equals(FileURI);
    }
  return false;
});

if (I == Files.end())
  Files.push_back(createFile(FE));

return std::distance(Files.begin(), I);

Or pre-compute the index before push_back if the container invalidates iterators upon push_back.

aaron.ballman marked an inline comment as done.Dec 14 2018, 1:18 PM
aaron.ballman added inline comments.
lib/StaticAnalyzer/Core/SarifDiagnostics.cpp
129

I dig it! Implemented in r349197.