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.
Although I don't plan to bring over new assertions wholesale
into the current qualification branch, it's entirely possible
that various minor changes in main will use the new assertions;
having this basic support in the release branch will simplify that.
(This is why I'm adding the includes as a separate pass from
rewriting the individual assertions)
Previously getReducedType() would dump debug info if we had an invalid
dependent member type, but an invalid root type parameter would cause
a segfault. Fix this.
I gated inverses on associated types behind a feature flag, but a
slightly older stdlib being rebuilt from source will now fail because it
used that functionality for `_Pointer` without the feature.
So, just permit the feature if we're working with a module built from
an interface file, to avoid this reverse condfail
.
We don't expect to see type parameters that are not generic parameters
here, but dependent member types that wrap an ErrorType are fine, they
show up when a conformance had an invalid type witness.
Fixes the remaining example from https://github.com/apple/swift/issues/59384.
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.
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>.
If we fail to build a generic signature (or requirement signature of a
protocol) because of a request cycle or because Knuth-Bendix completion
failed, we would create a placeholder signature with no requirements.
However in a move-only world, a completely unconstrained generic
parameter might generate spurious diagnostics when used in a copyable
way. For this reason, let's outfit these placeholder signatures with
a default set of conformance requirements to Copyable and Escapable.
Requirement lowering only expects that it won't see two requirements
of the same kind (except for conformance requirements). So only mark
those as conflicting.
This addresses a crash-on-invalid and improves diagnostics for
move-only generics, because a conflict won't drop the copyability
of a generic parameter and expose a move-only-naive user to
confusing error messages.
Fixes#61031.
Fixes#63997.
Fixes rdar://problem/111991454.
We were skipping the expansion of default requirements on generic
parameters when creating an abstract generic signature that adds only
new generic parameters, but no additional requirements.
- It's wasteful to cache because each invocation is unique
- Inference sources only need to be Types and not TypeLocs
- We can pass in an explicit SourceLoc for diagnostics
(cherry picked from commit 4e39dac206dd8e0818ca509f5f09f93425a48c62)
With the removal of `fromDefault` in StructuralRequirement,
`applyInverses` no longer could distinguish which reqirements came from
`expandDefaults` and which were explicitly written in source. Thus, for
a generic parameter like `<T> where T: Copyable, T: ~Copyable`, the
inverse `~Copyable` was eliminating the explicitly-written requirement,
causing `T` to be noncopyable.
We want to emit an error in such cases, so this swaps things around so
we only ever applyInverses on a requirements list that is from
expandDefaults.
When the Swift module is not available, we'll synthesize the
Copyable/Escapable decls into the Builtin module.
In the future, it might be nice to just do this always, and define
typealiases for those types in the stdlib to refer to the ones in the
builtin module.
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.
We already need to track the inverses separate from the members in a
ProtocolCompositionType, since inverses aren't real types. Thus, the
only purpose being served by InverseType is to be eliminated by
RequirementLowering when it appears in a conformance requirement.
Instead, we introduce separate type InverseRequirement just to keep
track of which inverses we encounter to facilitate cancelling-out
defaults and ensuring that the inverses are respected after running
the RequirementMachine.
