diagnostics: respect dumpdir when outputting SARIF and HTML file [PR110522]HEADtrunkmaster

PR diagnostics/110522 notes that when generating the output path for
diagnostics in SARIF or HTML form, the compiler ignores the path for the
compiler output, leading to race conditions and overwritten SARIF output
when compiling the same source file multiple times in a build.

Given e.g.

  gcc \
    -o build-dir/foo.o \
    -fdiagnostics-add-output=sarif
    foo.c

my intent was for the sarif sink to write to "build-dir/foo.c.sarif",
but in GCC 13 - GCC 15 it writes to "foo.c.sarif" instead.

The driver adds the option "-dumpdir build-dir" when invoking cc1, and
opts.cc's finish_options has the logic to prepend the dump_dir_name to
the dump_base_name, which in theory ought to have affected the name for
SARIF output.  The root cause is that finish_options is called *after*
processing the options for creating the diagnostic sinks, and so the
sarif_sink is created when dump_base_name is "foo.c", and thus
writes to "foo.c.sarif", rather than "build-dir/foo.c.sarif".

This patch introduces a new helper function for accessing the base name
for diagnostic sinks and refactors the prepending logic
in finish_options so that it is also used when creating diagnostic
sinks, so that in the above example the SARIF is written to
"build-dir/foo.c.sarif".

The patch took the number of .sarif files generated by the analyzer
integration tests from 5094 to 11309.  The most extreme example I could
find within them was where we previously got a single .sarif file:
  qemu-7.2.0/build/fpu_softfloat.c.c.sarif
and *with* the patch we get 66 .sarif files:
  qemu-7.2.0/build/libqemu-aarch64-linux-user.fa.p/fpu_softfloat.c.c.sarif
  qemu-7.2.0/build/libqemu-aarch64-softmmu.fa.p/fpu_softfloat.c.c.sarif
  [...snip lots of different architectures...]
  qemu-7.2.0/build/libqemu-xtensaeb-linux-user.fa.p/fpu_softfloat.c.c.sarif
  qemu-7.2.0/build/libqemu-xtensaeb-softmmu.fa.p/fpu_softfloat.c.c.sarif

which presumably were previously all being written to the same place
during the build.  Indeed, the old file is invalid JSON, and appears to
have been truncated.

gcc/ChangeLog:
	PR diagnostics/110522
	* gcc.cc (driver_handle_option): Use
	get_diagnostic_file_output_basename for
	OPT_fdiagnostics_format_.
	* opts-diagnostic.cc (get_base_filename): Likewise.
	(get_diagnostic_file_output_basename): New.
	* opts-diagnostic.h (get_diagnostic_file_output_basename): New
	decl.
	* opts.cc (maybe_prepend_dump_dir_name): New, based on code in
	finish_options.
	(finish_options): Move code for determining prepended
	dump_base_name to maybe_prepend_dump_dir_name and call it.
	(common_handle_option): Use get_diagnostic_file_output_basename
	for OPT_fdiagnostics_format_.
	* opts.h (maybe_prepend_dump_dir_name): New decl.

Signed-off-by: David Malcolm <dmalcolm@redhat.com>

0 files changed, 0 insertions, 0 deletions