stripping PackType out of diagnostic arguments.
There are places in the type printing code that assume the substitution for a
type parameter pack is always a pack, and violating that invariant will crash
the compiler. We also never want to print 'Pack{...}' in diagnostics anyway,
so the print option is a better approach and fixes a few existing tests that still
contained 'Pack{...}' in error messages.
Instead of diagnosing in CSApply, let's create a
fix and diagnose in the solver instead.
Additionally, make sure we assign ErrorTypes to
any VarDecls bound by the invalid pattern, which
fixes a crash.
rdar://110638279
type.subst in mapTypeIntoContext.
The outer context substitutions are already applied when invoking
QueryInterfaceTypeSubstitutions. Applying the context substitutions
before subst also causes problems because QueryInterfaceTypeSubstitutions
will return a null type if given an archetype, which manifested with
opened pack element environments.
Apply the same logic that we apply to other
conjunction elements, to make sure that e.g
property wrapper projected values work correctly.
rdar://110649179
Previously we would skip over ExprPatterns, but
we need to ensure that we walk them, as they may
have interesting variable references that the
closure needs to be connected to the type
variables for.
rdar://110617471
Previously if the cast was unresolved, we would
emit a warning and bail with `nullptr`. This is
wrong, because the caller expects a `nullptr`
return to mean we emitted an error. Change the
diagnostic to an error to fix this. This may
appear source breaking, but in reality previously
we were failing to add the cast at all in this case,
which lead to a crash in SILGen. We really do
want to reject these cases as errors, as this
will give us a better opportunity to fall back to
type-checking as ExprPatterns, and better matches
the constraint solver type-checking.
Also while we're here, change the diagnostic for
the case where we don't have an existential context
type from the confusing "enum doesn't have member"
diagnostic to the pattern mismatch diagnostic.
rdar://107420031
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.
This is wrong because there's nowhere to put any
conversion that is introduced, meaning that we'll
likely crash in SILGen. Change the constraint to
equality, which matches what we do outside of the
constraint system.
rdar://107709341
Previously we would wait until CSApply, which
would trigger their type-checking in
`coercePatternToType`. This caused a number of
bugs, and hampered solver-based completion, which
does not run CSApply. Instead, form a conjunction
of all the ExprPatterns present, which preserves
some of the previous isolation behavior (though
does not provide complete isolation).
We can then modify `coercePatternToType` to accept
a closure, which allows the solver to take over
rewriting the ExprPatterns it has already solved.
This then sets the stage for the complete removal
of `coercePatternToType`, and doing all pattern
type-checking in the solver.
This shouldn't be necessary, we should be able to
solve with type variables instead. This makes sure
we don't end up with weird special cases that only
occur when an external type is present.
- 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
This covers situations like `Pack{repeat each T1, repeat each T2}`
vs. `Pack{repeat $T1, repeat $T2}` where type variables are allowed
to bind to packs.
Resolves: rdar://109539394
If there are multiple overloads, let's skip locations that produce
the same type across all of the solutions, such location is most
likely a consequence of ambiguity and not its source.
Resolves: rdar://109245375
Opened existentials should be erased to the dependent upper bound
if the dependent member can be reduced to a concrete type. This
allows the generic signature to support parameterized protocol types
and bound generic class types by producing a more specific constraint
instead of just a plain protocol or class.
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
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.
We shouldn't be allocating placeholders for type
variables in the permanent arena, and we should be
caching them such that equality works.
To achieve this, we need to introduce a new
"solver allocated" type property. This is required
because we don't want to mark placeholder types
with type variable originators as themselves having
type variables, as it's not part of their structural
type. Also update ErrorType to use this bit, though
I don't believe we currently create ErrorTypes
with type variable originators.
