There is a strong desire for "no-implicit-copy" semantics to be
applied to Copyable values marked with the newer `borrowing` and
`consuming` ownership specifiers. If we lock ourselves into what
SE-390 specifies now for Copyable types in the implementation, then
we'll have to introduce a source break when we want such values to
have the desired semantics.
Before there's wider adoption, I'm making it an error to use those
newer names. If for some reason this is enabling a critical
optimization for your use case, please use the old names instead:
- `__owned` for `consuming` parameters
- `__consuming` for `consuming` methods
- `__shared` for `borrowing` parameters
NOTE: the older names have their ownership attribute mangled into
the name of the function itself, so there's a possibility of ABI
breaks in the future if you move from the old name to the new one.
There is some consideration being made to allow for a migration to
the new names in the future without breaking ABI, so do reach out if
this is an issue for you.
resolves rdar://108538971
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
Does not fix the fix-it. The current fix it will be left as a stop-gap solution and we can hopefully update this fix it in the near future to actually plop in a for loop (too much work for this PR though).
Diagnose situation when a single argument to tuple type is passed to
a value pack expansion parameter that expects distinct N elements:
```swift
struct S<each T> {
func test(x: Int, _: repeat each T) {}
}
S<Int, String>().test(x: 42, (2, "b"))
```
The constraint takes two pack types and makes sure that their
reduced shapes are equal. This helps with diagnostics because
constraint has access to the original pack expansion pattern
types.
If there are explicit generic arguments that fully resolves the
pack expansion, let's bind opened pack expansion to its contextual
type early (while resolving pack expansion variable), doing so
helps with performance and diagnostics.
If solver had to introduce an unlabeled single-element tuple around
contextual type, let's strip it and fix as a regular contextual mismatch
(instead of a tuple mismatch) because this action should be transparent
to diagnostics.
Just like in any other position, let's restore unresolved type variables
that represent generic parameters to their generic parameter type when
they are found in a pack expansion pattern type.
It's only safe to infer element type from `PackElementOf` constraint
when pattern type is fully resolved (because it can have pack element
archetypes which should be mapped out of context), the same applies
to the pattern type inference as well. Since constraints are re-activated
every time a referenced type variable is bound, simplication logic
can act as inference source by decaying into `Equal` constraints
where pattern/element type are resolved via surrounding information
first.
`openType` didn't need a locator before it was simply replacing generic
parameters with corresponding type variables but now, with opening of
pack expansions types, a locator is needed for pack expansion variables.
Pack expansion flattening could result in lose of tuple structure
or introduce a single element tuples (which are effectively parens),
to aid in matching `matchTypes` should introduce/maintain tuples on
both sides of the comparison until the structure is known.
Replace all `PackExpansionType` with a special type variable
which would be resolved once the solver determines that there
is enough contextual information.
Pack expansion type variable can only ever have one binding
which is handled by \c resolvePackExpansion.
There is no need to iterate over other bindings here because
there is no use for contextual types (unlike closures that can
propagate contextual information into the body).
This handles situations like `Int <conv> (Int, (_: $T_exp)` or
`String arg conv (_: $T_exp)`. The matching has to be delayed
because the structure of the tuple type is not known until `$T_exp`
(which represents a pack expansion type) is resolved.
Tuple types cannot be matched until all pack expansion variables
are resolved, the same is applicable to `shape of` constraints
because the structure of the pack is not fully resolved in such
cases.
Even if both sides are pack expansion variables they cannot be
merged because merging of them means merging of pattern and
shape types as well, which is easier to do when one of both
sides are bound.
A pack expansion type variable gets bound to its original pattern
type when solver can infer a contextual type for it. This makes
sure that pack expansion types are always matched via `matchTypes`
without `simplifyType` involvement which can expand them prematurely.
If a pattern type of a pack expansion doesn't have all of the "pack capable"
type variables bound, we don't know what the structure is yet and expansion
cannot be flattened.
Models `PackExpansionType` as a type variable that can only
bind to `PackExpansionType` and `expansion of` constraint that
connects expansion variable to its pattern, shape types.
We need to teach code completion how to invoke the type checker for attached macro attributes. After that, everything started working.
rdar://105232015
