We assumed that replacing a subcomponent of a CanType with another
CanType always produces a CanType. This is no longer true because
() throws(Never) -> () canonicalizes down to () -> ().
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.
Previously, inverses were only accounted-for in inheritance clauses.
This batch of changes handles inverses appearing in other places, like:
- Protocol compositions
- `some ~Copyable`
- where clauses
with proper attribution of default requirements in their absence.
Conflicts:
- `lib/AST/TypeCheckRequests.cpp` renamed `isMoveOnly` which requires
a static_cast on rebranch because `Optional` is now a `std::optional`.
The type that occurs as the thrown error type must conform to the
`Error` protocol. Infer this conformance when the type is a type
parameter in the signature of a function.
An initial implementation of a rework in how
we prevent noncopyable types from being
substituted in places they are not permitted.
Instead of generating a constraint for every
generic parameter in the solver, we produce
real Copyable conformance requirements. This
is much better for our longer-term goal of
supporting `~Copyable` in more places.
Replace the `front()` and `back()` accessors on `InheritedTypes` with dedicated
functions for accessing the start and end source locations of the inheritance
clause. NFC.
Wrap the `InheritedEntry` array available on both `ExtensionDecl` and
`TypeDecl` in a new `InheritedTypes` class. This class will provide shared
conveniences for working with inherited type clauses. NFC.
When we added same-shape requirements, we broke -analyze-requirement-machine,
which outputs some histograms. Add a regression test to make sure this code
path doesn't bitrot.
If the substitution terms of a concrete type symbol contain unresolved
name symbols, we have an invalid requirement that is dropped from the
minimized signature. In this case, the rewrite system used for minimization
cannot be installed as the official rewrite system for this generic
signature, because building a rewrite system from the signature will
produce a different result.
This might be the cause of the crash in rdar://114111159.
llvm::SmallSetVector changed semantics
(https://reviews.llvm.org/D152497) resulting in build failures in Swift.
The old semantics allowed usage of types that did not have an
`operator==` because `SmallDenseSet` uses `DenseSetInfo<T>::isEqual` to
determine equality. The new implementation switched to using
`std::find`, which internally uses `operator==`. This type is used
pretty frequently with `swift::Type`, which intentionally deletes
`operator==` as it is not the canonical type and therefore cannot be
compared in normal circumstances.
This patch adds a new type-alias to the Swift namespace that provides
the old semantic behavior for `SmallSetVector`. I've also gone through
and replaced usages of `llvm::SmallSetVector` with the
`Swift::SmallSetVector` in places where we're storing a type that
doesn't implement or explicitly deletes `operator==`. The changes to
`llvm::SmallSetVector` should improve compile-time performance, so I
left the `llvm::SmallSetVector` where possible.
We want `T.A == U.B` to imply `shape(T) == shape(U)` if T (and thus U)
is a parameter pack.
To do this, we introduce some new rewrite rules:
1) For each associated type symbol `[P:A]`, a rule `([P:A].[shape] => [P:A])`.
2) For each non-pack generic parameter `τ_d_i`, a rule `τ_d_i.[shape] => [shape]`.
Now consider a rewrite rule `(τ_d_i.[P:A] => τ_D_I.[Q:B])`. The left-hand
side overlaps with the rule `([P:A].[shape] => [shape])` on the term
`τ_d_i.[P:A].[shape]`. Resolving the overlap gives us a new rule
t_d_i.[shape] => T_D_I.[shape]
If T is a term corresponding to some type parameter, we say that `T.[shape]` is
a shape term. If `T'.[shape]` is a reduced term, we say that T' is the reduced
shape of T.
Recall that shape requirements are represented as rules of the form:
τ_d_i.[shape] => τ_D_I.[shape]
Now, the rules of the first kind reduce our shape term `T.[shape]` to
`τ_d_i.[shape]`, where `τ_d_i` is the root generic parameter of T.
If `τ_d_i` is not a pack, a rule of the second kind reduces it to `[shape]`,
so the reduced shape of a non-pack parameter T is the empty term.
Otherwise, if `τ_d_i` is a pack, `τ_d_i.[shape]` might reduce to `τ_D_I.[shape]`
via a shape requirement. In this case, `τ_D_I` is the reduced shape of T.
Fixes rdar://problem/101813873.
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.
Reformatting everything now that we have `llvm` namespaces. I've
separated this from the main commit to help manage merge-conflicts and
for making it a bit easier to read the mega-patch.
This is phase-1 of switching from llvm::Optional to std::optional in the
next rebranch. llvm::Optional was removed from upstream LLVM, so we need
to migrate off rather soon. On Darwin, std::optional, and llvm::Optional
have the same layout, so we don't need to be as concerned about ABI
beyond the name mangling. `llvm::Optional` is only returned from one
function in
```
getStandardTypeSubst(StringRef TypeName,
bool allowConcurrencyManglings);
```
It's the return value, so it should not impact the mangling of the
function, and the layout is the same as `std::optional`, so it should be
mostly okay. This function doesn't appear to have users, and the ABI was
already broken 2 years ago for concurrency and no one seemed to notice
so this should be "okay".
I'm doing the migration incrementally so that folks working on main can
cherry-pick back to the release/5.9 branch. Once 5.9 is done and locked
away, then we can go through and finish the replacement. Since `None`
and `Optional` show up in contexts where they are not `llvm::None` and
`llvm::Optional`, I'm preparing the work now by going through and
removing the namespace unwrapping and making the `llvm` namespace
explicit. This should make it fairly mechanical to go through and
replace llvm::Optional with std::optional, and llvm::None with
std::nullopt. It's also a change that can be brought onto the
release/5.9 with minimal impact. This should be an NFC change.
This source location will be used to determine whether to add a name lookup
option to exclude macro expansions when the name lookup request is constructed.
Currently, the source location argument is unused.
`InferredGenericSignatureRequest` creates `StructuralRequirement`s for
the requirements of the generic signature that is passed to it (if one
is).
Previously, it used invalid `SourceLoc`s for these requirements. The
result was that when errors that were emitted as a result of those
`StructuralRequirement`s (during concrete type contraction), they would
also have invalid `SourceLoc`s. The effect was that those errors were
ignored during `diagnoseRequirementErrors`.
Here, use the available loc for those requirements.
rdar://108963047
