Enhance the logic in `applyInverses` to also take into account same-type constraints spelled in
the generic signature, so that same-type-constraining a type parameter to a type that is itself
not `Copyable` or `Escapable` suppresses the default application of those constraints on the
type parameter. Fixes rdar://147757973.
https://github.com/swiftlang/swift/pull/72659 turned out to have some
source compatibility fallout that we need to fix. Instead of introducing
yet another brittle compatibility hack, stop emitting errors about a
missing `any` altogether until a future language mode.
Besides resolving the compatibility issue, this will encourage
developers to adopt any sooner and grant us ample time to gracefully
address any remaining bugs before the source compatibility burden
resurfaces.
A subsequent commit adds a diagnostic group that will allow users to
escalate these warnings to errors with `-Werror ExistentialAny`.
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.
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
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.
The checking for ExistentialAny diagnostics needed to be updated to both
handle the new Copyable/Escapable protocols that appear in the Any and
AnyObject existential layouts.
resolves rdar://123332844
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.
With NoncopyableGenerics, we get a cycle involving
`SuperclassTypeRequest` with this program:
public struct RawMarkupHeader {}
final class RawMarkup: ManagedBuffer<RawMarkupHeader, RawMarkup> { }
Because we generally don't support the following kind of relationship:
class Base<T: P>: P {}
class Derived: Base<Derived> {}
This commit works around the root-cause, which is that Derived's
synthesized conformance to Copyable gets superceded by the inherited one
from Base. Instead of recording conformances in the ConformanceLookup
table at all, create builtin conformances on the fly, since classes
cannot be conditionally Copyable or Escapable.
We weren't diagnosing conflicts in PCT's like `Copyable & ~Copyable`,
instead deferring until that PCT was constrained to something like the
existential Self or a generic parameter, which then we'd diagnose.
But we should canonicalize PCT's such as `Copyable & Copyable` into
`Any`, which represents the empty composition. That's what the assert in
PCT::build is about.
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.
The solution is to add the unconditional conformances when building the
conformance lookup table for each nominal, instead of waiting until
conformance lookup infers it.
At the moment, because the stdlib isn't being built with Copyable
conformances injected into it, we still end up needing to infer Copyable
conformances for nominals like `Int` from the stdlib when trying to test
the feature, since it loads those nominals, but they lack conformance.
That should go away once we do enable NoncopyableGenerics for the stdlib
by default, and we'll be left with only inferring the conditional
conformance in TypeCheckInvertible.
It should be the responsibility of callers to map the type to a
contextual type, as needed. When it's not possible or repetitive to do
so, there is a special-purpose function `isInterfaceTypeNoncopyable` for
Sema.
First, "can have an absence of Copyable" is a rather confusing notion,
so the query is flipped to "can be Copyable". Next, it's more robust to
ask if a conformance exists for the TypeDecl to answer that question,
rather than trying to replicate what happens within that conformance
lookup.
Also renames `TypeDecl::isEscapable` to match.
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.
