Move some deserialization error handling services to methods under ModuleFile.
This will give access to the ASTContext and allow to report diagnostics.
Also rename `consumeErrorIfXRefNonLoadedModule` into the more general
`consumeExpectedError` that is more appropriate for future improvements.
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.
Parse compound and special names in the macro role attributes
(`@freestanding` and `@attached`). This allows both compound names and
initializers, e.g., `init(coding:)`.
Fixes rdar://107967344.
When reading a swiftmodule that's part of the main module the compiler
should have access to all internal details. In that case, read the
underlying type to opaque types.
This was caught by `SILOptimizer/specialize_opaque_result_types2.sil`
which has a merge-module like behavior reading it sib files as input.
Clients of a resilient module using opaque types don't need access to
the underlying type unless it's used in an inlinable context. Plus, the
underlying type can reference internal details which can lead to crashes
when they reference implementation-only dependencies. To clean up this
behavior, let's only serialize the underlying type if used by an
inlinable function.
rdar://105128784
There is no related test as we don't have reproducer code and we've seen
it only in the debugger, but I believe the fix is sound on its own.
rdar://106430304
`__shared` and `__owned` would always get mangled, even when they don't have any effect
on ABI, making it unnecessarily ABI-breaking to apply them to existing API to make
calling conventions explicit. Avoid this issue by only mangling them in cases where they
change the ABI from the default.
And do a first pass of auditing existing uses of the parameter specifiers to
make sure that we look at the ValueOwnership mapping in most cases instead of
individual modifiers.
- Use the name lookup table instead of adding members from a macro expansion to the parent decl context.
- Require declaration macros to specify introduced names and used the declared names to guide macro expansions lazily.
Deserialization recovery lead the compiler to drop public constructors
overridding internal constructors. This limits the logic to dropping the
overriding relationship instead of the whole constructor. This applies
when the overriden constructor fails to deserialize and only when the
overriding relationship was marked as not affecting ABI.
rdar://104704832
- SILPackType carries whether the elements are stored directly
in the pack, which we're not currently using in the lowering,
but it's probably something we'll want in the final ABI.
Having this also makes it clear that we're doing the right
thing with substitution and element lowering. I also toyed
with making this a scalar type, which made it necessary in
various places, although eventually I pulled back to the
design where we always use packs as addresses.
- Pack boundaries are a core ABI concept, so the lowering has
to wrap parameter pack expansions up as packs. There are huge
unimplemented holes here where the abstraction pattern will
need to tell us how many elements to gather into the pack,
but a naive approach is good enough to get things off the
ground.
- Pack conventions are related to the existing parameter and
result conventions, but they're different on enough grounds
that they deserve to be separated.
The attached and freestanding macro attributes use the same parsing
logic and representation, so generalize the "attached" attribute into
a more general "macro role" attribute.
Describe attached macros with the `@attached` attribute, providing the
macro role and affected names as arguments to the macro. The form of
this macro will remain the same as it gains other kinds of attached
macro roles beyond "accessor".
Remove the "accessors" role from `@declaration`, which will be going
away.
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
Add support for freestanding declaration macros.
- Parse `@declaration` attribute.
- Type check and expand `MacroExpansionDecl`.
Known issues:
- Generic macros are not yet handled.
- Expansion does not work when the parent decl context is `BraceStmt`. Need to parse freestanding declaration macro expansions in `BraceStmt` as `MacroExpansionDecl`, and add expanded decls to name lookup.
