https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116744

            Bug ID: 116744
           Summary: RFE: can generated SARIF file be a container for
                    "everything" needed for a bug-report against gcc?
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Keywords: SARIF
          Severity: normal
          Priority: P3
         Component: other
          Assignee: unassigned at gcc dot gnu.org
          Reporter: hp at gcc dot gnu.org
                CC: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

In PR116724, we had this conversation:

> The use-case I was thinking of, is for the SARIF output to be
> a nice containment of the non-source-code part of bug-reports: "instead of
> quoting stderr, use --diagnostics-format=sarif-file and send
> sourcename.sarif".  

To which dmalcolm replied:

Sounds like an interesting idea; can you open this as a separate RFE please?

Me (still quoting conversation from that "bug"):
> But, to fulfill that, more is needed, including the gcc
> arguments.  (Maybe that's all.)

dmalcolm:

I've added support for capturing the command-line arguments in GCC 15:
  https://gcc.gnu.org/pipermail/gcc-patches/2024-July/658206.html
though note that it's capturing the arguments as supplied by the driver to e.g.
cc1, as opposed to those that the user supplied to the driver.
...
FWIW that SARIF can capture embedded copies of source files of interest, and
that the GCC SARIF generation code does this for any source file mentioned in a
diagnostic.  So perhaps the .sarif file could contain everything.

me (now continuing the conversation here):
(I suppose driver and preprocessor error message don't mention cc1!  And then,
at least I'm happy with cc1 as long as the contained file is the preprocessed
file.)

So, what's missing may be for the output-sarif-file to support holding the
actual input.  I didn't mention it because in the back of my mind I was
thinking that could be problematic: what if the user wanted to file a report
but not expose his actual source code, instead separately a cut-down
derivative?  On the other hand, using the option to output this
complete-report-contents file is a deliberate action, so we should be good as
long as the option has a well-chosen name i.e. not riding along on
-diagnostics-format=sarif-file (I amend that part of the request).

Reply via email to