Find all the usages of `--enable-experimental-feature` or
`--enable-upcoming-feature` in the tests and replace some of the
`REQUIRES: asserts` to use `REQUIRES: swift-feature-Foo` instead, which
should correctly apply to depending on the asserts/noasserts mode of the
toolchain for each feature.
Remove some comments that talked about enabling asserts since they don't
apply anymore (but I might had miss some).
All this was done with an automated script, so some formatting weirdness
might happen, but I hope I fixed most of those.
There might be some tests that were `REQUIRES: asserts` that might run
in `noasserts` toolchains now. This will normally be because their
feature went from experimental to upcoming/base and the tests were not
updated.
The reverse-condfail workaround needs to be removed, and this is the
first step to allowing the stdlib to build with conditionally escapable
types.
resolves rdar://132453000
It is no longer necessary to produce `.swiftinterface` files the support older
compilers that lack support for the NoncopyableGenerics feature. Cleaning this
up makes the stdlib `.swiftinterface` far more readable.
A generic signature's `getInnermostGenericParams` will find the generic
parameters in the innermost scope. That's not quite right for printing
inverses, since we don't want to print an inverse for `T` when emitting
the generic signature of `f` below:
```swift
struct S<T: ~Copyable, E> {
func f() where E == Never {}
}
```
Since `f` has its own generic signature, but doesn't define any generic
parameters, it shouldn't have an inverse emitted. The solution here is
to filter inverses by depth of the generic parameter.
We also want to print _all_ of the inverses in other situations, rather
than just the innermost ones. This aids in debugging and other
tools like the API digester.
resolves rdar://130179698
If the extension adds conformance to an invertible protocol, it's
confusing for people to also infer conditional requirements on the
generic parameters for those invertible protocols. This came up in the
review of SE-427.
The basic inheritance clause emission in ASTPrinter operates on
InheritedEntry's, but does not canonicalize types. It's been
designed to consider an entire composition unprintable because one
member is unprintable (e.g., the protocol is not public).
This rejection is what was causing `~Copyable` in some compositions to
be missing from interface files (rdar://126090425). Fixing that is the
purpose of this patch.
What happens, then, if you mix public and nonpublic protocols in a
composition? A second facility called the InheritedProtocolCollector
later does find the public protocols, and emits extensions at the end of
the interface file to declare the additional conformances the ininitial
declaration printer missed.
We can't generally emit `~Copyable` on an extension, so the fix can't
happening there. Refactoring things so there's one source of truth about
the protocols being printed is a sizable refactoring that I will defer
for another time.
resolves rdar://126090425
With the generalization of Optional to support noncopyable types, our
feature-guarding in swiftinterface files would double-print functions
that simply refer to the Optional type.
Since NoncopyableGenerics is a suppressible feature, by default
a second version of Optional and UnsafePointer are emitted into
swiftinterface files, where the ~Copyable generalization is stripped
away.
We can rely on that to avoid double-printing the function, if the types
substituted for the generic parameters are all Copyable.
We need a bit more checking for when
`@_disallowFeatureSuppression(NoncopyableGenerics)` is used, since this
trick relies on there always being a definition of the type we refer to,
whether the feature is enabled or not.
resolves rdar://127389991
Add the machinery to support suppression of inference of conformance to
protocols that would otherwise be derived automatically.
This commit does not enable any conformances to be suppressed.
It doesn't really make sense for a conditional conformance requirement
for `Copyable` to depend on any other requirement other than other
`Copyable` conformance requirements.
resolves rdar://124967739
The model for associated types hasn't been fully worked-out for
noncopyable generics, but there is some support already that is being
used by the stdlib for an internal-only (and rather cursed) protocol
`_Pointer` to support `UnsafePointer`, etc.
This patch gates the existing experimental support for associated types
behind a feature flag. This flag doesn't emit feature-guards in
interfaces, since support for it is tied closely to NoncopyableGenerics
and has been there from its early days.
When printing declarations with `NoncopyableGenerics2` suppressed we must avoid
printing the `@_preInverseGenerics` attribute and any `borrowing` or
`consuming` parameter ownership modifiers.
Nested types with inverse requirements on generic parameters would
sometimes print incorrectly. We only print the inverses on outer generic
parameters for extensions.
fixes rdar://123281976
When a NoncopyableGenericsMismatch happens between the compiler and
stdlib, allow the compiler to rebuild the stdlib from its interface
instead of exiting with an error.
We want extensions to introduce default Copyable/Escapable just like
other generic contexts, so that once Optional adopts ~Copyable,
an `extension Optional` actually adds `Wrapped: Copyable` by default.
In cases where the generic parameter is class-constrained,
`GenericSignature::requiresProtocol` will not contain `Copyable` or
`Escapable` because GenericSignature minimization will recognize that
the class already requires them.
Thus, because classes always require those protocols, we can
simply ask if the generic parameter is required to be a class to
determine if it had any inverses.
Follow the feature flag convention for capitalization and be
consistent with the related NoncopyableGenerics feature.
This is a new feature that no wild Swift code has used it yet:
commit e99ce1cc5d
Author: Kavon Farvardin <kfarvardin@apple.com>
Date: Tue Dec 5 23:25:09 2023
[NCGenerics] add `~Escapable`
Basic implementation of `~Escapable` in the type system.
We can't simply emit the desugared, expanded version of the requirements
because there's no way to pretty-print the type `some ~Copyable` when
the `~Copyable`'s get replaced with the absence of `Copyable`. We'd be
left with just `some _` or need to invent a new top type so we can write
`some Top`. Thus, it's best to simply reverse the expansion of default
requirements when emitting a swiftinterface file.
