For batch compile jobs, it's helpful to see which files are considered primary
and that was the original reason why filelist contents were printed in compiler
crash stack dumps. However, for whole module compile jobs, the contents of the
filelist is uninteresting (it's just all the files in the module) and can be
hundreds or thousands of lines long so it often causes important information to
be trimmed from stack dumps received in reproducers.
While this will be in the compiler arguments, it's easy to miss when
skimming over the pretty stacktrace. Add an explicit message to make it
easier to see while looking over crashes.
Outputting the effective version in the pretty stack trace was skipped
if the current version was the same as the effective version. This would
result in an empty line, which is somewhat confusing. Output a line
regardless.
Resolves rdar://81140703
Rather than outputting diagnostics and to stderr, output all the extra
information added when deserialization fatally fails to the pretty stack
trace instead. Since the pretty stack trace is added to crash logs, this
should avoid the dance of requesting the compiler output
- Moves the previous "**** DESERIALIZATION FAILURE ..." output to the
last pretty stack trace line
- Removes the module and compiler version notes added to the fatal
diagnostic
- Adds a new effective compiler version line for all frontend failure.
Somewhat duplicates the line from the driver, but adds in the
effective version
- Adds a new line for the full misc version of the module that failed.
May double up with previous "While reading from ..." lines that are
added in various deserialization methods, but better to have it
twice than not at all
It's currently not obvious in crash reports whether compiling with
errors is enabled or not. Since this option can make previously
"impossible" paths now possible, add a message to both the pretty stack
output and fatal deserialization diagnostics to point out that it is
enabled.
This obviates the need for "-frontend", although we still accept it
for backward compatibility. Switch lit's %target-swift-frontend et al
over to calling swift-frontend.
Clang 8 or 9 seems to have changed from EXE to exe. Allow both
capitalizations (which is not important in Windows) as a workaround.
Maybe in the future we can remove the uppercase option.
As pointed out on a recent JIRA, crash traces don't mention what
version of Swift you were running. Usually that can be gleaned from
the path, but not always.
To display stack traces from child processes, the driver combines stdout
and stderror together on Unix. This makes the Basic implementation also
do that.
This may help us reproduce a failing build when all we have is a build
log, and will become much more important in batch mode when we
/really/ need to know what ended up in what batch.
For now, this doesn't include /output/ filelists, because David's
about to mess with that code anyway to make things better around
supplementary outputs in batch mode. There is one weirdness there,
though, which is that ArgsToFrontendInputsConverter peeks at the
outputs to see whether we're doing single-threaded or multi-threaded
WMO.
