In situations like this:
```swift
func foo(x: (Int, Int) {}
foo(x: 0, 0)
```
Left paren to form a missing tuple should be placed after
the label because belongs to the parameter and not the tuple.
Number the parameters starting at 1 in order to
match other diagnostics such as
diag::missing_argument_positional, and change the
text to make it explicit that we're referring to
the parameter position (rather than argument
position).
This commit changes `getArgumentExprFor` to take
a ConstraintLocator argument from which to find
the argument list. This lets us properly handle
the case where we have a key path subscript
locator. In addition, this commit renames the
member to `getArgumentListExprFor` to make it
clear we're returning the argument list expression
rather than a single argument.
Resolves SR-11562.
Structurally prevent a number of common anti-patterns involving generic
signatures by separating the interface into GenericSignature and the
implementation into GenericSignatureBase. In particular, this allows
the comparison operators to be deleted which forces callers to
canonicalize the signature or ask to compare pointers explicitly.
Due to the fact that `matchCallArgument` can't and
doesn't take types into consideration while matching
arguments to parameters, when both arguments are
un-labeled, it's impossible to say which one is missing:
func foo(_: Int, _: String) {}
foo("")
In this case first argument is missing, but we end up with
two fixes - argument mismatch (for #1) and missing argument
(for #2), which is incorrect so it has to be handled specially.
Now that the generic signature is computable on demand, this predicate is doubly useless. All of the callers intended to ask "hasInterfaceType" anyways.
Like the last commit, SourceFile is used a lot by Parse and Sema, but
less so by the ClangImporter and (de)Serialization. Split it out to
cut down on recompilation times when something changes.
This commit does /not/ split the implementation of SourceFile out of
Module.cpp, which is where most of it lives. That might also be a
reasonable change, but the reason I was reluctant to is because a
number of SourceFile members correspond to the entry points in
ModuleDecl. Someone else can pick this up later if they decide it's a
good idea.
No functionality change.
Most of AST, Parse, and Sema deal with FileUnits regularly, but SIL
and IRGen certainly don't. Split FileUnit out into its own header to
cut down on recompilation times when something changes.
No functionality change.
`MissingArgumentsFailure::diagnoseClosure` can actually diagnose both
closures in argument positions as well as when their type comes from
context e.g. `let _: (Int) -> Void = {}`.
Instead of storing contextual function type in the fix/diagnostic,
let's fetch it from context (solution and/or locator) because it's
only used when it is a trailing closure missing some arguments anyway.
If missing conformance is between two stdlib defined types which
are used in operator invocation, let's produce a generic diagnostic
about operator reference and a note about missing conformance.
If expression is incorrect it most likely wouldn't be able to satisfy
`Equatable` or other requirements of `~=` operator overloads, but
at the same time the main problem is related to `case` expression
itself so let's not diagnose missing conformances.
In absence of general argument conversion failures requirement
errors associated with operators couldn't be diagnosed properly,
now this restriction could be lifted.
There is logic in `matchTypes` which would unwrap l-value if other
type is not an `inout`, which is not great for cases where parameter
type is a pointer and argument is an l-value which requires explicit
`&` to be converted.
