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.
This commit adds a new frontend flag that applies debug path prefixing to the
paths serialized in swiftmodule files. This makes it possible to use swiftmodule
files that have been built on different machines by applying the inverse map
when debugging, in a similar fashion to source path prefixing.
The inverse mapping in LLDB will be handled in a follow up PR.
Second pass at #39138
Tests updated to handle windows path separators.
This reverts commit f5aa95b381.
* Fix unnecessary one-time recompile of stdlib with -enable-ossa-flag
This includes a bit in the module format to represent if the module was
compiled with -enable-ossa-modules flag. When compiling a client module
with -enable-ossa-modules flag, all dependent modules are checked for this bit,
if not on, recompilation is triggered with -enable-ossa-modules.
* Updated tests
This is intended to be used from LLDB to apply the remappings
specified in target.source-map to remap any serialized
Swiftmodule search paths that were prefixed using
`-prefix-serialized-debugging-options`.
This commit adds the `-prefix-serialized-debugging-options` flag,
which is used to apply the debug prefix map to serialized debugging
options embedded in the swiftmodule files.
Serialization was reporting that it did not have fingerprints for these declarations. When combined with the driver's new type body fingerprint work for extensions, this effectively hid changes to the bodies of these nested types from the driver's incremental build infrastructure.
Make sure we recur into all of the iterable decl contexts when serializing decls to collect as many fingerprints as we can.
rdar://83469936
Some Swift module versions are beyond the scope of llvm::VersionTuple(), thus we need to sanitize the most
trivial bits so that we can handle most cases in versioned canImport query.
