Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sourcemaps or #line directives #618

Open
ratmice opened this issue Dec 17, 2023 · 5 comments
Open

Sourcemaps or #line directives #618

ratmice opened this issue Dec 17, 2023 · 5 comments

Comments

@ratmice
Copy link

ratmice commented Dec 17, 2023

Reading through the spec, I was curious because I didn't see anything that mentioned line directives or sourcemaps. I'm curious if this has been discussed, and whether there is a reasonable mechanism for it within the spec that I missed, or an intention that this be handled externally by some too taking a sarif file and a sourcemap and translating the relevant locations, or whether this is something that could be considered in the future.

@KalleOlaviNiemitalo
Copy link

KalleOlaviNiemitalo commented Dec 18, 2023

Perhaps transpiled or minimized code could be indicated by making a result object (§3.27) list the corresponding locations in both files, linking them together via a locationRelationship object (§3.34), and setting a dedicated value in the "kinds" property (§3.34.3).

If the original source is in a different programming language not understood by the SARIF producer, then I suppose it won't be able to produce any fix objects (§3.55) that would propose changes to the original file.

@ratmice
Copy link
Author

ratmice commented Dec 18, 2023

Regarding your last observation, in our case it's more like a template engine where verbatim code in the target language is interspersed with generated code. In theory if a fix fully overlaps the target, and the producer and the template language translator both understand SARIF, it seems possible that we could translate some fixes.

Edit: If I understand I think the existing "includedBy"/"includes", cover this exact kind of relationship

@KalleOlaviNiemitalo
Copy link

From the example in §3.34.1, it seems "includes" and "isIncludedBy" are intended for cases like the #include directive in C, i.e. an artifact does not actually contain text copied from another artifact, but contains a directive that causes tools to read the other artifact.

@ratmice
Copy link
Author

ratmice commented Dec 18, 2023

Yeah, bit of a brain fart there, so it is probably best to leverage the "a SARIF producer MAY use any value." value clause with something else, perhaps "verbatimCopiedBy". "verbatimCopied"

@sthagen
Copy link
Contributor

sthagen commented May 1, 2024

I like to discuss this within the TC as I try to minimize the number of MAY statements. In addition, I think this question deserves an answer on the intentions of the TC members in the existing specification. Also, we may find a way to achieve a more clear specification in the future.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants