These tests are using FileCheck to check the result of diagnostic
formatting in ways that don't match the new formatter. Force the old
formatter or, where possible, generalize so that they match both
formatters.
Currently, ModuleFileSharedCore::fatal() calls abort(), which may be reasonable
in a swift-frontend invocation, but has dire consequences when the Swift
frontend is embedded into another process, for example, LLDB where the abort()
kills the entire debugging session.
This patch introduces a few alternatives to the ModuleFile::fatal() familiy of
functions that instead push a fatal diagnostic to the ASTContext's
DiagnosticsEngine and return an llvm::Error so the error can be roperly
communicated and the ASTContext can be wound down without killing the parent
process.
The transition is not complete, this patch does not yet handle
fatalIfUnexpected(), for example.
This patch is NFC for the Swift compiler: When DebuggerSupport in off
ModuleFile::diagnoseFatal() will still call abort(), but if it is on, the error
will be passed up, together with a pretty stack trace.
rdar://64511878
Instead, stimulate users to follow the referenced bug reporting guidelines,
which contain all the necessary information. We’d rather encourage attempts
at reducing issues before attaching Xcode projects. This is an accompaniment
to https://github.com/apple/swift-org-website/pull/158.
Many deserialization failures at this points are caused by archives
installed over the SDK. Let's extend the current error message with a
solution for such a case.
rdar://86280699
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
The new message is:
"Please submit a bug report (https://swift.org/contributing/#reporting-bugs) and include the crash backtrace."
1. In crash logs we used to print a message which points to the llvm bug tracking page. Now it points to the swift.org bug tracking guidelines.
2. Use the same message in all compiler diagnostics which ask the user to file a bug report.
rdar://problem/70488534
That is, a Swift 3 target imported into a Swift 4 context or vice
versa. This requires serializing the compatibility mode explicitly,
instead of including it in the textual version string that's only
for debugging.
