Checking whether a declaration is in a `.swiftinterface` is a very common query
that is made somewhat awkward because declarations are not always in source
files. To make these checks more ergonomic, expose a convenience on
DeclContext.
When using `-experimental-skip-all-function-bodies` we don’t run the `TypeCheckSourceFileRequest` and thus don’t go through the decl checker, which calls `InheritedTypeRequest` on all inheritance clauses. This means that the inherited entries are not populated by the time we serialize the module. Trigger the computation of inherited entries by calling `InheritedTypeRequest` during serialization.
Unfortunately, we can’t use the type returned by `getResolvedType` for the serialization because `getResolvedType` returns an inverted protocol type for suppressed conformances but during serialization, we want to serialize the suppressed type with a `isSuppressedBit`. We thus need to call `getEntry(i).getType()` again to get the type to serialize.
rdar://141440011
The problem with `is_escaping_closure` was that it didn't consume its operand and therefore reference count checks were unreliable.
For example, copy-propagation could break it.
As this instruction was always used together with an immediately following `destroy_value` of the closure, it makes sense to combine both into a `destroy_not_escaped_closure`.
It
1. checks the reference count and returns true if it is 1
2. consumes and destroys the operand
This is used for synthetic uses like _ = x that do not act as a true use but
instead only suppress unused variable warnings. This patch just adds the
instruction.
Eventually, we can use it to move the unused variable warning from Sema to SIL
slimmming the type checker down a little bit... but for now I am using it so
that other diagnostic passes can have a SIL instruction (with SIL location) so
that we can emit diagnostics on code like _ = x. Today we just do not emit
anything at all for that case so a diagnostic SIL pass would not see any
instruction that it could emit a diagnostic upon. In the next patch of this
series, I am going to add SILGen support to do that.
Most of the compiler should use SemanticAvailableAttr instead. In contexts like
ASTDumper where a semantic attribute is unavailable use accessors on
AvailableAttr.
NFC.
On reading out a 'ProtocolConformanceXrefLayout', instead of querying the protocol on the 'NominalDecl' referenced by the Xref, use the general-purpose lookup that resolves implicit conformances to e.g. 'Sendable'.
Otherwise, we can end up in a situation where a library serializes some type as (implicitly) conforming to Sendable, but the client, upon deserialization, has not yet run implicit Sendable inference logic, so its representation of said type will not match.
This failure will most-likely result in the dependency query failure which will fail the scan. It will be helpful if the scanner emitted diagnostic for each such module it rejected to explain the reason why.
Resolves rdar://142906530
Now that AvailableAttr has storage for its cached AvailabilityDomain, it's no
longer necessary to store an AvailabilityDomain inline in
SemanticAvailableAttr.
NFC.
decl being accessed is correct. When this assumption fails due to a deserialization error
of its members, the use site accesses the layout with a wrong field offset, resulting in
UB or a crash. The deserialization error is currently not caught at compile time due to
LangOpts.EnableDeserializationRecovery being enabled by default to allow for recovery of some
of the deserialization errors at a later time. In case of member deserialization, however,
it's not necessarily recovered later on.
This PR tracks whether member deserialization had an error by recursively loading members and
checking for deserialization error, and fails and emits a diagnostic. It provides a way to
prevent resilience bypassing when the deserialized decl's layout is incorrect.
Resolves rdar://132411524
This attribute makes it so that a parameter of the annotated type, as well as
any type structurally containing that type as a field, becomes passed as
if `@_addressable` if the return value of the function has a dependency on
the parameter. This allows nonescapable values to take interior pointers into
such types.
In https://github.com/swiftlang/swift/pull/77156, normalization was introduced
for -target-variant triples. That PR also caused -target-variant arguments to
be inherited from the main compilation options whenever building dependency
modules from their interfaces, which is incorrect. The -target-variant option
must only be specified when compiling a "zippered" module, but the dependencies
of zippered modules are not necessarily zippered themselves and
indiscriminantly propagating the option can cause miscompilation.
The new, more targeted approach to normalizing arm64e triples simply uses the
arch and subarch of the -target argument of the main compile to decide whether
the subarch of both the -target and -target-variant arguments of a dependency
need adjustment.
Resolves rdar://135322077 and rdar://141640919.
Right now it is basically a version of nonisolated beyond a few simple cases
like constructors/destructors where we are pretty sure we want to not support
this.
This is part of my bringup strategy for changing nonisolated/unspecified to be
caller isolation inheriting.
I need this today to add the implicit isolated parameter... but I can imagine us
adding more implicit parameters in the future, so it makes sense to formalize it
so it is easier to do in the future.
Extend the module trace format with a field indicating whether a given
module, or any module it depends on, was compiled with strict memory
safety enabled. This separate output from the compiler can be used as
part of an audit to determine what parts of Swift programs are built
with strict memory safety checking enabled.
