https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116613
--- Comment #7 from Kamil Dudka <kdudka at redhat dot com> --- (In reply to Eric Gallager from comment #6) > Yeah, in particular, I'd want to send text to stdout while also sending > SARIF to a file that shares the input file's name, except with the .sarif > extension. (i.e., compiling foo.c would create foo.sarif) This does not work well for source code files that are generated during the build. They can be created in temporary directories that are later removed during the build. A source code file with the same path (such as conftest.c) can be compiled repeatedly with different contents inside, etc. I have been developing fully transparent capture and processing of GCC diagnostic output since 2013: https://github.com/csutils/ Now in 2024 we are still using the plain-text diagnostic output of GCC because the currently provided interface for configuring GCC diagnostic output does not make it easy for us to use a JSON-based format. This was previously discussed here: https://github.com/packit/dashboard/issues/441#issuecomment-2307711956 For fully automated capture of GCC diagnostic output that works regardless of the build system, it would be much more useful if GCC was able to write a separate SARIF file with a unique file name for each compilation unit to a specified directory, something like `valgrind --xml-file=${dir}/%p-%n.xml ...` does.
