`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.
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.
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.
Introduce `ConstraintSystem::recordTypeVariablesAsHoles` as a
standard way to record that unbound type variables found in a
type are holes in the given constraint system.
* Use fancy arrows (`→`) because they are distinct from and shorter than `->`,
and fancier.
* We have two ways of demarcating locators: `@ <locator>` and `[[<locator>]];`.
Stick to the first, which is shorter and clearer.
* 'attempting type variable' → 'attempting binding'. *Bindings* are attempted,
not type variables.
* `considering ->` → `considering:`. I think a colon is semantically more fit
and makes things easier to read if the considered constraint has arrows in its
description or types. It’s also shorter this way.
For a `@Testable` import in program source, if a Swift interface dependency is discovered, and has an adjacent binary `.swiftmodule`, open up the module, and pull in its optional dependencies. If an optional dependency cannot be resolved on the filesystem, fail silently without raising a diagnostic.
For example @objc lookup could find multiple instance members
on `AnyObject`. It should be allowed to diagnose issues with
that as non-ambiguous if all fixes have the same kind/base type.
Resolves: rdar://102412006
For an external property wrapper, there may not be
a pattern here. I believe this should only be hit
during `-debug-constraints` or if there's a too
complex error (which I'm not sure is possible to
produce in this case), so no test.
element environments.
This allows the constraint system to ensure that for a given pack expansion locator,
the given shape class is always the same when requesting the element environment.
If the shape class differs, it means there's a same-shape requirement failure, which
will be diagnosed via the ShapeOf constraint simplification.
Fill in some nodes that previously weren't being
walked, and bail with `None` if the walk is
terminated, rather than filling the resulting
SolutionApplicationTarget with null pointers.
This method currently isn't called anywhere, but
I'm planning on using it shortly, so this is an
NFC change for now.
Generic arguments types are not always resolved enough to enable
aggregated mismatch fixes, which means that the solver should be
able to handle standalone generic argument matching constraints
and create a fix per mismatch location to coalesce them during
diagnostics.
Resolves: rdar://106054263
