Make sure we flush the diagnostics consumers to prevent the new
diagnostic style to buffer the deserialization errors without printing
them. These errors may be printed right before an `abort()`, which would
bypass the actual printing of the errors.
Take advantage of the new style to make these diagnostics more readable
as well.
```
.../LibWithXRef.swiftmodule:1:1: remark: reference to type 'MyType'
broken by a context change; 'MyType' was expected to be in 'A', but now
a candidate is found only in 'A_related'
1 │ A.MyType
│ ├─ remark: reference to type 'MyType' broken by a context change;
'MyType' was expected to be in 'A', but now a candidate is found only in
'A_related'
│ ├─ note: the type was expected to be found in module 'A' at
‘.../A.swiftmodule'
│ ├─ note: or expected to be found in the underlying module 'A'
defined at ‘.../module.modulemap'
│ ├─ note: the type was actually found in module 'A_related' at
‘.../A_related.swiftmodule'
│ ├─ note: the module 'LibWithXRef' was built with a Swift language
version set to 5.10 while the current invocation uses 4.1.50; APINotes
may change how clang declarations are imported
│ ├─ note: the module 'LibWithXRef' has enabled library-evolution; the
following file may need to be deleted if the SDK was modified:
‘.../LibWithXRef.swiftmodule'
│ ├─ note: declarations in the underlying clang module 'A' may be
hidden by clang preprocessor macros
│ ├─ note: the distributed module 'LibWithXRef' refers to the local
module 'A'; this may be caused by header maps or search paths
│ ╰─ note: the type 'MyType' moved between related modules; clang
preprocessor macros may affect headers shared between these modules
.../LibWithXRef.swiftmodule:1:1: note: could not deserialize type for
'foo()'
1 │ A.MyType
│ ╰─ note: could not deserialize type for 'foo()'
```
rdar://124700605
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.
This PR makes diagnostics on deserialization errors caused by project
configuration more helpful by providing contextual information on the
issue:
- Path to the modules involved (up to 4 modules): the loaded swiftmodule
with the broken outgoing reference, the path to the module where the
decl was expected, the path to the underlying clang module, and the path
to the module where the decl was found. This information should prevent
us from having to ask for a different log with `-Rmodule-loading`.
- Hint to delete the swiftmodule files when the module is
library-evolution enabled.
- Hint that clang settings affect clang modules involved in this
scenario.
- Pointing out when a decl moved between two modules with a similar name
(where one name is a prefix of the other). This is a common issue when
headers are shared between a clang framework's public and private
modules.
- Pointing out layering issues when an SDK module imports a local
module.
- Pointing out Swift language version mismatch which may lead to the
compiler viewing the same clang decls differently when they are modified
by APINotes files.
Use the `attempting forced recovery` diagnostic as main warning to which
we attach other messages as notes. Also mention the flag in the
diagnostic to reinforce that the flag is active.
Intro a deserialization mode controlled by the flag
`-experimental-force-workaround-broken-modules` to attempt unsafe
recovery from deserialization failures caused by project issues.
The one issue handled at this time is when a type moves from one module
to another. With this new mode the compiler may be able to pick a
matching type in a different module. This is risky to use, but may help
in a pinch for a client to fix and issue in a library over which they
have no control.
The Swift compiler expects the context to remain stable between when a
module is built and loaded by a client. Usually the build system would
rebuild a module if a dependency changes, or the compiler would rebuilt
the module from a swiftinterface on a context change. However, such
changes are not always detected and in that case the compiler may crash
on an inconsistency in the context. We often see this when a clang
module is poorly modularized, the headers are modified in the SDK, or
some clang define change its API.
These are project issues that used to make the compiler crash, it
provided a poor experience and doesn't encourage the developer to fix
them by themselves. Instead, let's keep track of modularization issues
encountered during deserialization and report them as proper errors when
they trigger a fatal failure preventing compilation.
