This commit changes fixit messages from a question/suggestion to an
imperative message for protocol conformances and switch-case. Addresses
https://github.com/apple/swift/issues/67510.
This change causes explicit types written in the
source language that substitute a noncopyable type
for a type variable in a generic type to state
that's what's wrong. For example:
```
// NEW: noncopyable type 'MO' cannot be used with generic type 'Dictionary<Key, Value>' yet
// OLD: noncopyable type 'MO' cannot be used with generics yet
let _: [MO : T]
```
- replaces "move-only" terminology with "noncopyable"
- replaces compiler jargon like "guaranteed parameters"
and "lvalue" with corresponding language-level notions
- simplifies diagnostics about closures.
and probably more.
rdar://109281444
If we don't split up the tuple into individual constraints,
we end up spending more time querying whether a tuple is
Copyable in `lookupConformance`, because it will naively
check the types of all elements of the tuple recursively
with `lookupConformance`.
This is inefficient because if we know some of the elements
of the tuple are fixed types, we don't need to keep checking
those again. For example, if we have `($T, Int, $U)`, and
then try a binding for `$T`, we might ask again if the whole
tuple conforms. Leading to `lookupConformance` to check
whether `Int` (and all other elements of the tuple) conforms
to Copyable, when we either already know that, or can't
answer it yet because it's still a type variable.
By splitting up a Copyable constraint on a tuple into
invidivual constraints on each of its type elements,
we can avoid this redundant work by `lookupConformance`.
While today we could short-cut this even further to say
that _all_ tuples are Copyable, since we emit an error if
a noncopyable type appears in one, that won't be true in
the near future. This is the nicer solution we'll want to
keep around long-term.
After discussing this with Pavel, we don't think there's a
good way to add a regression test for this, because the
performance issue primarily comes up in specific example
programs that aren't amenable to scale tests.
resolves rdar://107536402
These metatypes are a gateway to more incorrect
uses of these noncopyable values because we don't
yet have the corresponding runtime support yet.
The other use cases of using metatypes of
noncopyable types in generics is not high enough to
warrant people using them yet.
resolves rdar://106452518
These are the same semantically, just the mangling is slightly different. The
benefit of doing this is that we are actually testing what we expect our users
to do.
rdar://108511703
the main things still left behind the experimental flag(s) are
- move-only classes (guarded by MoveOnlyClasses feature)
- noimplicitcopy
- the _borrow operator
The _Copyable constraint was implemented as a marker protocol.
That protocol is part of the KnownProtocol's in the compiler.
When `ASTContext::getProtocol(KnownProtocolKind kind)` tries
to find the ProtocolDecl for Copyable, it will look in the
stdlib module (i.e., Swift module), which is where I initially
planned to put it.
That created problems initially when some regression tests
use `-parse-stdlib` failed to do that protocol lookup, which is
essential for adding the constraint (given the current implementation).
That led to believe we need to pull Copyable out of the stdlib, but that's
wrong. In fact, when building the Swift module itself, we do `-parse-stdlib`
but we also include `-module-name Swift`. This causes the _Copyable protocol
defined in the Stdlib to be correctly discovered while building the stdlib
itself (see the test case in this commit). So, the only downside of
having the Copyable protocol in the Stdlib is that `-parse-stdlib` tests
in the compiler can't use move-only types correctly, as they'll be
allowed in generic contexts. No real program would build like this.
Until I have time to do a further refactoring, this is an acceptable trade-off.
fixes rdar://104898230
It appears that conditional casts require a check of the
type's metadata at runtime. There's no reason for us to
permit that at this time, since all such conditional
casts are going to fail, unless its the identity cast.
That is, a move-only type is currently only a subtype
of itself.
So for now, `is`, `as?`, `as!` casts from or to a
move-only type are now an error. The `as` casts
are permitted only if the two move-only types are
equal.
where `MO` is a move-only type.
turns out it was being allowed because the cast is represented as a
disjunction in the constraint solver:
- `MO conv AnyObject`
- `MO bridge conv AnyObject`
I caught the first one but missed the second, which was unconditionally
being allowed.
Since structs and enums only participate in subtyping via protocols,
move-only types that are structs and enums effectively are only
subtypes of themselves.
Since values of generic type are currently assumed to always
support copying, we need to prevent move-only types from
being substituted for generic type parameters.
This approach leans on a `_Copyable` marker protocol to which
all generic type parameters implicitly must conform.
A few other changes in this initial implementation:
- Now every concrete type that can conform to Copyable will do so. This fixes issues with conforming to a protocol that requires Copyable.
- Narrowly ban writing a concrete type `[T]` when `T` is move-only.
