As specified in SE-0441, -language-mode should appear in help output
while -swift-version should be the hidden alias.
Related to swiftlang/swift-driver#1894
Non-Escapable 'inout' arguments have a default self-dependency, regardless of
any other annotations. For example:
@_lifetime(dest: copy source)
/* DEFAULT: @_lifetime(dest: copy dest, copy source) */
func foo<T: ~Escapable>(dest: inout T, source: T)
An immortal lifetime specifier now suppresses that default. For example:
@_lifetime(dest: immortal, copy source)
/* DEFAULT: @_lifetime(dest: copy source) */
func foo<T: ~Escapable>(dest: inout T, source: T)
This is necessary because there is otherwise no other way to suppress the
default lifetime.
Fixes rdar://170016708 ([nonescapable] Support @_lifetime(immortal) to suppress
the usual inout default self-dependency)
Qualification has discovered a complicated test case where the module interface printer incorrectly adds module selectors to nested types that don’t support them. Tweak module interface printing to omit the module selector in more situations.
Fixes rdar://169720990.
In #86859, I modified the way `export_as` names are used in private module interfaces so that the `export_as` name is used when that module has been imported. This turns out to be slightly too aggressive in a specific scenario where a submodule of the export_as module imports a submodule of the real module—the compiler ends up using the export name even though the resulting lookup won’t actually work.
Modify the logic for deciding whether to use an exported module name so that it not only checks whether the export_as module has been loaded, but also whether the specific module or submodule the declaration belongs to is (possibly transitively) imported by that module.
Fixes rdar://167874630 (harder).
Given that we implicitly expanded Copyable & Escapable
conformance requirements for suppressed primary associated
types, we now need this function to do the opposite;
filtering Copyable & Escapable requirements on such primary
associated types and adding inverses if those requirements
are missing.
This function plays a crucial role in emitting the interface
files accurately for functions and types, in addition to
how we mangle generic signatures into function symbols.
The mangling for generic signatures under the -WithDefaults version of
suppressed associated types goes like this:
- primary associated type T.A has an inverse `Rj` or `RJ` mangled
into the generic signature if it lacks the conformance, or
nothing is mangled into it.
- non-primary associated type T.B has either a `T.B: Copyable`
requirement mangled into it, or nothing is mangled into it.
For the legacy SuppressedAssociatedTypes feature, where there's no
defaults, it uses the "non-primary assocated type" mangling strategy
for all generic signatures.
If printing is for a package interface, let's add derived/implied `Sendable`
conformance to avoid having to infer it while type-checking the interface
file later. Such inference is not always possible, because i.e. a package
declaration can have private storage that won't be printed in a package
interface file and attempting inference would produce an invalid result.
Resolves: rdar://166159992
Assume a default dependency for all 'inout' parameters regardless of the
presence of an explicit annotation.
Default to `@lifetime(inoutArg: copy inoutArg)` even if an explicit annotation
exists.
This way API authors do not need to make the inout dependency explicit when they
probably always want that and don't normally need to write it.
Now:
```
@_lifetime(a: copy b)
func foo(a: inout T, b: T)
```
implies:
```
@_lifetime(a: copy a, copy b)
func foo(a: inout T, b: T)
```
Fixes rdar://169835235 (Always default inout dependencies)
The `@reparented` was missing and a typealias
was being synthesized unexpectedly, creating
an issue when typechecking the interface later.
There's no fundamental reason why typealiases
cannot be supported to say the same thing as
the same-type requirement, but I think the
same-type requirement is always needed to be
written on the extension, one way or another.
For now I've chosen to only go with an
explicitly-written same-type requirement.
Don't trasfer "preconcurrency" from isolation onto a declaration if
the declaration doesn't support it. This is especially important for
`MainActor` by default mode where each `@MainActor` injection site
gets marked as `@preconcurrency` implicitly in pre-6 language modes.
Resolves: https://github.com/swiftlang/swift/issues/85564
When both `-alias-module-names-in-module-interface` and `-enable-module-selectors-in-module-interface` are turned on, the compiler now disables the former with a warning. Eliminates workaround hacks that should no longer be necessary.
Fixes rdar://problem/169132519.
Previously, if a declaration belonged to a module with an `export_as` attribute, Swift always used the exported module name in the public module interface and the real module name in the private module interface. However, this is only a rough approximation of the behavior we really want, which is to use the real name in module interfaces that might be imported by dependencies of the exported name.
Change this logic so that public interfaces always use the exported name, and private interfaces use the exported name *only* if a module with that name has been loaded. This should make it so that if you’re building the `export_as` module or anything that imports it, you use the exported name; otherwise you use the real name.
Fixes rdar://167874630.
This does not rename all the internal variables, functions, and types
whose names were based on the old syntax.
I think it adds new syntax support everywhere it's needed while
retaining enough of the old syntax support that early adopters will
see nice deprecation messages guiding them to the new syntax.
The old `-module-interface-preserve-types-as-written` workaround flag prevents module selectors from being printed into module interfaces even when they have been explicitly requested. Disable it and emit a warning when it’s used in combination with `-enable-module-selectors-in-module-interface`.
Fixes rdar://166237384.
There were a number of cases where Swift would emit module selectors into module interface files that it was subsequently unable to parse because the compiler at least temporarily represented them as dependent member types. Modify the carve-out so that if *any* of a type’s parents are generic parameters or archetypes, we don’t print a module selector on it.
Fixes rdar://166180424.
The type of an outermost property wrapper should be printed together
with (inferred) generic arguments because otherwise if a any wrapper
in the chain has generic parameters that are not involved in
`wrappedValue:` argument it won't be impossible to infer them while
type-checking the interface file where it appears.
Resolves: rdar://122963120
For consistency with invertible protocols using `~Sendable` should
only prohibit use of unconditional extensions.
For example:
```swift
struct G<T>: ~Sendable {}
```
The following (unconditional) extension is rejected:
```
extension G: Sendable {} // error: cannot both conform to and suppress conformance to 'Sendable'
```
But conditional on `T` is accepted:
```
extension G: Sendable where T: Sendable {} // Ok!
```
