Deserialization may fail if a decl in a dependency changed type between the
time a swiftmodule was built and when it was imported. This can happen because
of changes to the SDK or use of C preprocessor macros. To help understand these
problems, note the specific types causing the mismatch when it leads to a
deserialization failure.
```
.../LibWithXRef.swiftmodule:1:1: error: reference to top-level
declaration 'foo' broken by a context change; the declaration kind of
'foo' from 'A' changed since building 'LibWithXRef'
1 │ A.foo
│ │ ├─ ...
│ ├─ note: a candidate was filtered out because of a type mismatch;
expected: '() -> ()', found: '(Int) -> Float'
```
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.
Deserialization recovery silently drops errors and the affected decls.
This can lead to surprises when a function from an imported module
simply disappears without an explanation.
This commit introduces the flag -Rmodule-recovery to report as remarks
some of these previously silently dropped issues. It can be used to
debug project configuration issues.
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.
The crash on `SILFunction type mismatch` provides little information and
tends to be difficult to reproduce. Let's print some of the available
information and distinguish the two failure sites.
I'm not confident all required information is written down so we may
need to improve this further in the future. This version still crashes
the compiler, we may want a proper type-check to prevent this failure
with a clean diagnostic for the example used here.
rdar://53821031
If the underlying type of an opaque type references an
implementation-only imported type, drop the underlying type information.
Without this fix, once we enable deserialization safety, we see crashes
or dropped decls in more existing tests:
IRGen/mangle-opaque-return-type.swift
IRGen/opaque_result_type_private_underlying.swift
Serialization/Recovery/implementation-only-opaque-type.swift
rdar://103238451
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
Instead of failing constraint generation by returning `nullptr` for an `ErrorExpr` or returning a null type when a type fails to be resolved, return a fresh type variable. This allows the constraint solver to continue further and produce more meaningful diagnostics.
Most importantly, it allows us to produce a solution where previously constraint generation for a syntactic element had failed, which is required to type check multi-statement closures in result builders inside the constraint system.
This adds tracking of the vtable holes due to a failure to deserialize
vtable entries. This allows for the user to be able to identify what
member failed to be deserialied and can aid in understanding why an
`open` class may not be subclassed.
Future improvements here would allow tracing the XRefPath which failed
to be deserialied. However, this still provides an improvement over the
existing experience where there is no available information on why the
class cannot be inherited from.
A type dependencies are used at deserialization to drop a protocol early
when a dependency is not deserializable. Dependencies on protocols via a
protocol composition were not taken into account. This lead to the
deserialization process failing later. Fix the serialization process to
write protocol dependencies too.
rdar://78631465
Access to a missing member on an AnyObject triggers a typo correction
that looks at all class members in imported modules. Make sure it
recovers from deserializing members referencing implementation-only
imported types.
rdar://79427805
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
In the added test case, the `typealias` refers to the `HiddenStruct` type in the private module, which is imported as `@_implementationOnly`. Because the import is `@_implementationOnly`, during deserialization, we don’t import the private module and hence any reference to the `HiddenStruct` type fails. In the common deserialization code path, this causes us to skip over the `typealias` member. However, when creating the protocol conformance, we assume that we can resolve the type to which the `typealias` refers and thus we are crashing.
If `LangOpts.EnableDeserializationRecovery` is set to `true`, we should do our best to recover from such failures so this patch makes the deserialization failure handling more graceful and resolve the right-hand side of the `typealias` as an `ErrorType`.
Fixes rdar://72891807
While the comment is correct to state that this won't enable any
new optimizations with -Onone, it does enable IRGen's lazy
function emission, which is important for 'reasync' functions,
which we don't want to emit at all even at -Onone.
This fixes debug stdlib builds with the new reasync versions
of the &&, || and ?? operators.
