Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hi there!
Thank you for building this library and a happy holidays! This PR aims to resolve #467 and add support for outputting Stan's observations as SARIF files. To support this, I wrote a new library,
sarif
, which implements the relevant types to represent SARIF structures and to serialise/deserialise them to/from JSON.The approach taken by my implementation is as follows:
sarif
library--sarif
, which instructs Stan to produce output in the SARIF formatStan.SARIF
, contains functions to convert from Stan's representations to those used for SARIFsarif
libraryWhat's this good for?
SARIF files can be understood by other tools, such as GitHub Code Scanning. For example, I used the changes made in this PR to run Stan on itself and upload the results to Code Scanning, which will then show a list of all observations:
These can be viewed in detail:
How can I do this?
To reproduce this, simply run
stan --sarif > stan.sarif
and use theupload-sarif
action to upload the file as part of a GitHub Actions workflow.Questions / Points of note
sarif
library depends onaeson
whilestan
depends onmicroaeson
. Ifsarif
is added as a dependency tostan
, thenaeson
becomes a transitive dependency. Therefore, any benefits with respect to fewer dependencies obtained from usingmicroaeson
are lost. The different libraries in use here also lead to some minor complications in the integration between the two projects (e.g. with respect to writing custom properties, such as tags).--sarif
option currently "overrides" the--json-output
option (i.e. if both are specified, the output is formatted as SARIF, which sort of makes sense because SARIF is also JSON). I see a few options here:--json-output
option entirely in favour of SARIF outputI'd appreciate a review of this and your thoughts on all of the above! Thanks!