There's still plenty of more work to do here for
pattern diagnostics, including introducing a
bunch of new locator elements, and handling things
like argument list mismatches. This at least lets
us fall back to a generic mismatch diagnostic.
Order them such that if they were changed to
conversions, they would be sound. This shouldn't
make a difference, but unfortunately it turns out
pattern equality is not symmetric. As such, tweak
the pattern equality logic to account for the
reversed types. This allows us to remove a special
case from function matching.
The TypedPattern and IsPattern constraints were
incorrectly written, with conversions propagating
out of the patterns, when really conversions
ought to propagate into patterns. In any case, it
seems like we really want equality here. Fix the
constraints to use equality, and have the cast
constraint operate on the external pattern type
instead of the subpattern type.
Don't attempt to wrap `Any` into a single-element tuple to match
against a tuple with pack expansions, this conversion would be
handled by existential promotion if it's allowed, otherwise it
would produce an error.
Resolves: rdar://109160060
SE-390 concluded with choosing the keyword discard rather than forget for
the statement that disables the deinit of a noncopyable type. This commit
adds parsing support for `discard self` and adds a deprecation warning for
`_forget self`.
rdar://108859077
Failure of an argument to AnyHashable parameter to conform to Hashable
protocol should be detected in `simplifyConformsToConstraint` and fixed
there.
Doing so requires impact assessment adjustment because regular conformance
requirements have default impact of 1, this is going to have argument
impact of 2 not avoid clashing with other failures.
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
Rather than eagerly binding them to holes if the
sequence element type ends up being Any, let's
record the CollectionElementContextualMismatch fix,
and then if the patterns end up becoming holes,
skip penalizing them if we know the fix was
recorded. This avoids prematurely turning type
variables for ExprPatterns into holes, which
should be able to get better bindings from the
expression provided. Also this means we'll apply
the logic to non-Any sequence types, which
previously we would give a confusing diagnostic
to.
We no longer need to check for a type variable
here, it no longer regresses diagnostics. Also,
while here, let's bump the impact for an
Any/AnyObject missing conformance, as that's
unlikely going to be helpful since they cannot
conform to protocols even if the user wanted them
to.
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
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.
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.
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.
