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
This source location will be used to determine whether to add a name lookup
option to exclude macro expansions when the name lookup request is constructed.
Currently, the source location argument is unused.
Expand macros in the specified source file syntactically (without any
module imports, nor typechecking).
Request would look like:
```
{
key.compilerargs: [...]
key.sourcefile: <file name>
key.sourcetext: <source text> (optional)
key.expansions: [<expansion specifier>...]
}
```
`key.compilerargs` are used for getting plugins search paths. If
`key.sourcetext` is not specified, it's loaded from the file system.
Each `<expansion sepecifier>` is
```
{
key.offset: <offset>
key.modulename: <plugin module name>
key.typename: <macro typename>
key.macro_roles: [<macro role UID>...]
}
```
Clients have to provide the module and type names because that's
semantic.
Response is a `CategorizedEdits` just like (semantic) "ExpandMacro"
refactoring. But without `key.buffer_name`. Nested expnasions are not
supported at this point.
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.
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.
Instead of walking the single ASTNode from the
target, walk all AST nodes associated with the
target to find the completion expr. This is needed
to find the completion expr in a pattern for an
initialization target.
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
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.
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.
`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.
