Just like we do with SILFunction, allow a code generation model to be
specified on a SILGlobalVariable and maintain that through the printed
and serialized forms.
Declarations that are potentially used externally, including those
exposed to foreign languages (e.g., via `@c`), placed in a specific
section (`@section`), or explicitly marked used (`@used`) are
generally eagerly emitted in IR. Embedded Swift was overriding this in
a partial manner, applying specific linkage rules to them to force
them to have unique definitions (regardless of the code generation
model) and then overriding the behavior later on when it came to lazy
emission.
Remove the special cases for Embedded. These declarations will now
follow the same linkage rules as all other declarations, greatly
simplifying the "is non-unique definition" check, and will be
considered as being emitted non-lazily.
The default code generation model for Embedded Swift is "inlinable".
DeferredCodeGen made the default code generation model
"implementation", and there was no spelling for "interface".
Introduce the experimental feature CodeGenerationModel=<model>, which
can be any of those three options. The default remains "inlinable", but
one can now specify "implementation" (which keeps most everything in
SIL) or "interface" (which only keeps the generic things in SIL). The
"interface" mode is more like non-embedded Swift for non-generic
declarations, emitting them into the IR (only) but not SIL. Generic
declarations would remain in SIL.
Implements rdar://172433062.
The code generation model for a particular declaration or conformance
can be defined explicitly with `@export(interface)`,
`@export(implementation)`, or `@inlinable` (for declarations),
indicating where the definition will occur.
Embedded Swift also has some limitations on what can be emitted into
IR. For example, a generic function cannot be `@export(interface)`
because Embedded Swift does not support unspecialized generics.
Compute the effective code generation model based on what was
explicitly specified, the limitations of the model, and the default
code generation model for the given module, which defaults to
"inlinable" but can be made "implementation" by the DeferredCodeGen
feature. Use the effective code generation model for IR- and SIL-level
determinations of linkage and where to emit symbols.
[WIP] Start computing and using the "effective" code generation model
FIXUP linkage of the alias symbol
* `assert` -> `ASSERT` for checking if an instruction is deleted twice. This will let us catch an error also with non-assert compiler builds.
* add checks that a deleted instructions is not used and is not using other values
This will hopefully give us more information for some rare non-deterministic compiler crashes.
rdar://176816390
rewriteIntegerTypes unwrapped the outer (Self) -> ... curry layer for
any instance member, constructor, or static decl. SubscriptDecl
interface types are not curried this way (they are already
(Args) -> Element), so the strip overshot into the bare element type
and the subsequent getParams() dereferenced garbage.
Gate the unwrap on hasImplicitSelfDecl(), which is the precise
condition for having an outer Self curry layer.
rdar://177482177
This ensures MemberImportVisibility diagnostics about missing imports of
CoreFoundation for `CGFloat.init(_:)` get a source location.
Resolves rdar://177380270.
`emitThrow` previously asserted that the only legal mismatch between the
in-flight error type and the throw destination was `any Error`, then
existential-erased to `Error`. Anything else Sema accepted — `do
throws(any P) where P: Error`, or a class subtype of the destination —
crashed the assertion (or, before that was tightened, miscompiled at
runtime).
Dispatch on the destination type:
- existential: erase, looking up conformance to each protocol in the
destination's existential layout (so `any P` works, not just `any
Error`);
- class: emit an `upcast`.
Anything else still hits an `unreachable` — Sema rejects those today, so
hitting it would indicate a Sema regression rather than a missing SILGen
path.
Fixes https://github.com/swiftlang/swift/issues/83826.
- Fix issue with no build id showing up as `000000`... (e.g. no debug
info), now shows as `<no build id>` as intended.
- Try to avoid loading PE file unless it's necessary on Windows
symbolicating backtraces.
- DefaultSymbolLocator: PDB file finding now respects the overridable
path for use in the offline symbolicator (no effect on standard
backtracing).
- Record timestamp/size in Image Info on windows for possible future use
in offline symbolicator
---------
Co-authored-by: Carl Peto <carlpeto@Carls-MacBook-Pro.local>
The substitution is driven by a canonical type to mangled name table on ASTContext,
populated by exportability checking at the same site where the corresponding
diagnostics are suppressed. After this change, the module emitter and module
loader see hidden types differently: the emitter still sees the real types
defined in the bridging header, while the loader sees only a mangled name
wrapped in a HiddenType placeholder.
This is not supported for the same reason you can't have a noncopyable
variadic parameter, but the code was hard-coded to check for copyability
only.
Generalize this to apply the generic signature for Array via the
common code path, and add a custom note to explain why those requirements
are checked in the first place.
Cleaning this up also fixed some fuzzer crashes.
Reported on the forums:
https://forums.swift.org/t/variadic-escapable-arguments-crash-the-compiler/86727/2
Some new logic was added in 8bb3bf09fb but
it would overwrite a contextual type stored in the 'type' local variable
with an interface type.
Instead, let's only map the type into the generic environment after we
figure out what's going on with the property wrapper.