As specified by the SE-0446 acceptance, extensions that declare a type's
conditional `Copyable` or `Escapable` ability must reiterate explicitly all
of the `Copyable` and/or `Escapable` requirements, whether required or not
required (by e.g. `~Copyable`) that were suppressed in the original
type declaration.
This was never used to generate a .swiftinterface, so can be safely removed. It
was used to guard compiler fixes that might break older .swiftinterface
files. Now, we guard the same fixes by checking the source file type.
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.
Use the `%target-swift-5.1-abi-triple` substitution to compile the tests for
deployment to the minimum OS versions required for use of opaque types, instead
of disabling availability checking.
Use the `%target-swift-5.1-abi-triple` substitution to compile the tests for
deployment to the minimum OS versions required for use of _Concurrency APIs,
instead of disabling availability checking.
We don't really want to support this, at least not yet, but there
are ways to sneak it past the diagnostic that are hard to close.
Fixes rdar://problem/135348472.
If location (member) isn't mutable in the current context
or there are other problems at this location, increase impact
of the fix since it compounds the problem.
Some editors use diagnostics from SourceKit to replace build issues. This causes issues if the diagnostics from SourceKit are formatted differently than the build issues. Make sure they are rendered the same way, removing most uses of `DiagnosticsEditorMode`.
To do so, always emit the `add stubs for conformance` note (which previously was only emitted in editor mode) and remove all `; add <something>` suffixes from notes that state which requirements are missing.
rdar://129283608
Attempting to bypass the compiler and access runtime functions directly has
a long history of breaking in hard-to-predict ways, and there's usually a better
way. Put up a warning to try to flush out misuses of runtime functions to see
if we can turn this into an error.
Not all runtimes can correctly operate with types that use noncopyable
generics. When the generic argument of a type is noncopyable, old
runtimes can't recognize that to correctly check conformances that may
be conditional on those arguments being Copyable, etc.
resolves rdar://126239335
In Swift 5.10 if you wrote `extension Foo {}` for some protocol Foo,
the extension would always re-use the generic signature of Foo, which
is <Self where Self: Foo>. In Swift 6 this no longer works because Foo
might be ~Copyable, in which case `extension Foo {}` adds default
requirements, so we changed GenericSignatureRequest to just always
build a new signature if we're given an extension.
However, to avoid a request cycle with a code example that really should
have never worked at all, I'm re-introducing the hack for re-using the
signature.
Fixes rdar://problem/129540617.
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.
Removing the old, ad-hoc diagnostics code improves the diagnostics we
emit, since the existing diagnostics for missing conformances is already
pretty good.
rdar://127369509
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.
Noncopyable types were prevented from having failable initializers
because `Optional` itself didn't support noncopyable types. Now
`Optional` does, so lift this restriction and add a test.
This changes the minimized signature in a very narrow edge case.
If you have
class C : P {}
and also
protocol P : C {}
protocol P where Self : C {}
then <T where T : P, T : C> now becomes <T : P> both with spellings;
before, the first one gave <T : P> and the second <T : C>.
