We noticed some Swift clients rely on the serialized search paths in the module to
find dependencies and droping these paths altogether can lead to build failures like
rdar://85840921.
This change teaches the serialization to obfuscate the search paths and the deserialization
to recover them. This allows clients to keep accessing these paths without exposing
them when shipping the module to other users.
We've recently added the -experimental-hermetic-seal-at-link compiler flag,
which turns on aggressive dead-stripping optimizations and assumes that library
code can be optimized against client code because all users of the library
code/types are present at link/LTO time. This means that any module that's
built with -experimental-hermetic-seal-at-link requires all clients of this
module to also use -experimental-hermetic-seal-at-link. This PR enforces that
by storing a bit in the serialized module, and checking the bit when importing
modules.
This cleans up 90 instances of this warning and reduces the build spew
when building on Linux. This helps identify actual issues when
building which can get lost in the stream of warning messages. It also
helps restore the ability to build the compiler with gcc.
Required for UnsafeRawPointer.withMemoryReboud(to:).
%out_token = rebind_memory %0 : $Builtin.RawPointer to %in_token
%0 must be of $Builtin.RawPointer type
%in_token represents a cached set of bound types from a prior memory state.
%out_token is an opaque $Builtin.Word representing the previously bound
types for this memory region.
This instruction's semantics are identical to ``bind_memory``, except
that the types to which memory will be bound, and the extent of the
memory region is unknown at compile time. Instead, the bound-types are
represented by a token that was produced by a prior memory binding
operation. ``%in_token`` must be the result of bind_memory or
Required for UnsafeRawPointer.withMemoryRebound(to:)
%token = bind_memory %0 : $Builtin.RawPointer, %1 : $Builtin.Word to $T
%0 must be of $Builtin.RawPointer type
%1 must be of $Builtin.Word type
%token is an opaque $Builtin.Word representing the previously bound types
for this memory region.
This is a signal to the move value kill analysis that this is a move that should
have diagnostics emitted for it. It is a temporary addition until we add
MoveOnly to the SIL type system.
These restrictions are meant to keep placeholder types from escaping TypeCheckType. But there's really no harm in that happening as long as we diagnose it on the way out in the places it's banned. (We also need to make sure we're only diagnosing things in primaries, but that's a minor issue). The end result is that we lose information because a lot of the AST that has placeholders in it becomes filled with error types instead.
Lift the restriction on placeholders appearing in the interface type, teach the mangler to treat them as unresolved types, and teach serialization to treat them as error types.
Stage in the parsing for this attribute, nothing else.
Motivated by two important reasons:
1) The pitch for variadic generics does not lay down a concrete syntax
for variadic generic parameters.
2) Paring T... and T* needlessly complicate the lexer as we must now
disambiguate them with respect to other internal operator characters
(e.g. `T...>` must lex as `(T...)>` and not `T ...>`
Which itself adds another motivation
3) We need to start parsing this attribute *now* to avoid condfail'ing
ourselves later.
I am purposely doing this in SILGen rather than at the type system level to
avoid having to have to add a bunch of boilerplate to the type system. Instead
of doing that, I am in SILGen checking for the isNoImplicitCopy bit on the
ParamDecl when we emit arguments. At that point, I set on the specific
SILArgument being emitted the bit that it is no implicit copy. In terms of
printing at the SIL level, I just printed it in front of the function argument
type like @owned, e.x.:
func myFunc(_ x: @_noImplicitCopy T) -> T {
...
}
becomes:
bb0(%0 : @noImplicitCopy @owned $T):
Some notes:
* Just to be explicit, I am making it so that no implicit copy parameters by
default are always passed at +1. The reason why I think this makes sense is
that this is the natural way of working with a move only value.
* As always, one can not write no implicit copy the attribute without passing
the flag -enable-experimental-move-only so this is NFC.
rdar://83957088
The key thing is that the move checker will not consider the explicit copy value
to be a copy_value that can be rewritten, ensuring that any uses of the result
of the explicit copy_value (consuming or other wise) are not checked.
Similar to the _move operator I recently introduced, this is a transparent
function so we can perform one level of specialization and thus at least be
generic over all concrete types.
The old message `(see "While..." info below)` is misleading ever since
we moved the serialization failure information to the stacktrace as the
context appears before this error. Plus this message should only be
shown for low-level errors when the data read is unexpected, so in cases
of a corrupted swiftmodule file or when there's a collision between two
different serialization formats. Let's make it more clear and direct.
Some notes:
1. This is not actually wired up to any part of codegen. Instead, this PR just
has the code necessary to parse the attribute and to ensure that we use it only
on local lets. The rest will come in subsequent commits.
2. I am allowing for the attribute to be attached to generic things in Sema
since we do not have enough information in the TypeChecker to distinguish in
between structs with a type parameter but that have all non-generic stored vars
from one with generic stored vars. We can only support the later with opaque
values but the former we can support without opaque values (and is one of the
use cases we are interested in).
rdar://83957088
This attribute creates an unavailable extension with a `Sendable` conformance so that the type is explicity marked as not being `Sendable`.
We also fully suppress diagnostics about unavailable Sendable conformances in Swift 5 mode code. (This is not fully developed yet—it should return to being a warning in concurrent contexts.)
The behavior when a @_nonSendable and a Sendable conformance are both on the same type is also not right yet.
This was a relict from the -sil-serialize-all days. This linkage doesn't make any sense because a private function cannot be referenced from another module (or file, in case of non-wmo compilation).
[Module Aliasing] Modify module loaders to use module 'real name' (physical name on-disk) when loading, since it can be different from 'name' if module aliasing is used. Also use the 'real name' to add/retrieve loaded modules in ASTContext. Resolves rdar://83591943.
Add ModuleInterface option meta tag for -module-alias
Add tests loading modules with -module-alias for swiftmodule and swiftinterface
with various loaders incl. serialized, explicit, and source loader.
