Recover from a raw type hidden behind an internal or implementation-only
import by dropping the whole enum when the raw type is unavailable. This
scenario should happen only when looking at non-public decl for indexing or
debugging, or if dependencies somehow changed and left behind a stale
swiftmodule file.
rdar://147091863
When deserialization a protocol conformance from a binary swiftmodule
file the compiler can encounter inconsistencies caused by stale module
files. Replace the hard crash with a proper error and print the list of
requirements and conformances being compared to stderr for manual
inspection. Recover silently when we can afford to, during indexing or
in LLDB.
Failures in `readNormalProtocolConformanceXRef` are usually caused by a
dependency change without the required rebuild of its dependents.
Display a proper error instead of crashing when encountering such an
issue during normal compilation. Recover silently when we can afford to,
during indexing or in LLDB.
This test appears flaky and it looks to be related to errors on modules
in the SDK from the timing with other failures. The flackiness is likely
from non-determinism in the module cache. Update the test to use a local
cache, which is a good practice for any test importing a module from the
SDK.
rdar://144272339
The diagnostics about unintended override of Objective-C methods
deserializes more decls than strictly necessary. Any of these could
trigger a deserialization failure if they rely on missing dependencies.
Simply ignore methods failing to deserialize instead of crashing.
We could do better here as this logic may ignore methods that are actually
colliding. Instead we could put more information in the lookup table to
avoid the need for fully deserializing the decl.
rdar://138764733
Some editors use diagnostics from SourceKit to replace build issues. This causes issues if the diagnostics from SourceKit are formatted differently than the build issues. Make sure they are rendered the same way, removing most uses of `DiagnosticsEditorMode`.
To do so, always emit the `add stubs for conformance` note (which previously was only emitted in editor mode) and remove all `; add <something>` suffixes from notes that state which requirements are missing.
rdar://129283608
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.
