The flow was such that we recorded subtype constraints regardless of the
subject type's nature. Extract value generics handling out of the
devious `else if` chain, and never record any subtype constraints if the
subject type is a non-type parameter.
While we're here, generalize the diagnostic message for user-written
subtype constraints on value generic parameters and emit it
consistently, not just if the right-hand side contains a protocol type.
We would crash in some cases, or produce a slightly misleading
diagnostic about same-element requirements, which are related but
not quite the same.
In the fullness of time, we should figure out this corner of the
language. Until then, add a new diagnostic since this is really
about same-type requirements between concrete types and packs.
Fixes rdar://159790557.
Convert a bunch of places where we're dumping to stderr and calling
`abort` over to using `ABORT` such that the message gets printed to
the pretty stack trace. This ensures it gets picked up by
CrashReporter.
Some requirement machine work
Rename requirement to Value
Rename more things to Value
Fix integer checking for requirement
some docs and parser changes
Minor fixes
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)
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.
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.
Originally I tried to implement a fancy redundant-inverse error
diagnostic that identifies the "previous" requirement already seen. I
ended up removing this error diagnostic because it was tricky to
implement well and we weren't diagnosing other redundant requirements.
Turns out we do have a mode of the compiler to diagnose redundant
requirements, but as warnings, using `-warn-redundant-requirements`.
This warning is much simpler in that it just points to one requirement
that is redundant.
Since there is no propagation of inverse constraints in the requirement
machine, we need to fully desugar these requirements at the point of
defining a generic parameter. That desugaring involves determining which
default conformance requirements need to be applied to a generic
parameter, accounting for inverses.
But, nested generic contexts in scope of those expanded generic
parameters can still write constraints on that outer parameter. For
example, this method's where clause can have its own constraints on `T`:
```
struct S<T> {
func f() where T: ~Copyable {}
}
```
But, the generic signature of `S` already has a `T: Copyable` that was
expanded. The method `f` will always see a `T` that conforms to
`Copyable`, so it's impossible for `f` to claim that it applies for
`T`'s that lack Copyable.
Put another way, it's not valid for this method `f`, whose generic
signature is based on its parent's `S`, to weaken or remove requirements
from parent's signature. Only positive requirements can be
added to them.
We're not yet going to allow noncopyable types into packs, so this
change prevents the use of `~Copyable` on an `each T` generic parameter.
It also fixes how we query for whether a `repeat X` parameter is
copyable.
This basically undoes 3da6fe9c0d, which in hindsight was wrong.
There were no other usages of TypeArrayView anywhere else except for
GenericSignature::getGenericParams(), and it was almost never what
you want, so callers had to convert back and forth to an ArrayRef.
Remove it.
`getValue` -> `value`
`getValueOr` -> `value_or`
`hasValue` -> `has_value`
`map` -> `transform`
The old API will be deprecated in the rebranch.
To avoid merge conflicts, use the new API already in the main branch.
rdar://102362022
Note the test cases in abstract_type_witnesses used to pass but are now
rejected. This is fine, because doing anything more complicated used to
crash, and the GSB would crash or misbehave with these examples.
Anthony Latsis
Slava Pestov
Hamish Knight
Alejandro Alonso
Tim Kientzle
Kavon Farvardin
Holly Borla
Erik Eckstein