With `ARCMigrate` and `arcmt-test` removed from clang in
https://github.com/llvm/llvm-project/pull/119269 and the new code
migration experience under way (see
https://github.com/swiftlang/swift-evolution/pull/2673), these options
are no longer relevant nor known to be in use. They were introduced
long ago to support fix-it application in Xcode.
For now, turn them into a no-op and emit a obsoletion warning.
Let's not perform $T? -> $T for closure result types to avoid having
to re-discover solutions that differ only in location of optional
injection.
The pattern with such type variables is:
```
$T_body <conv/subtype> $T_result <conv/subtype> $T_contextual_result
```
When `$T_contextual_result` is `Optional<$U>`, the optional injection
can either happen from `$T_body` or from `$T_result` (if `return`
expression is non-optional), if we allow both the solver would
find two solutions that differ only in location of optional
injection.
Doing it in the post-walk meant we ended up
walking the children twice, which lead to duplicate
diagnostics and incorrect inference of the
level of application for function references. Move
it to the pre-walk, ensuring that we resolve any
operator references before folding.
An extraneous argument doesn't have a corresponding parameter so the
information object for such an argument is not safe to produce.
Resolves: https://github.com/apple/swift/issues/60436
Resolves: rdar://98304482
Emit the specialized extraneous trailing closure
diagnostic for multiple trailing closures and
unlabelled unary argument lists, and add a
specialized trailing closure version for the multiple
extraneous case.
Unfulfilled params get arguments synthesized for them which are added
to the end of the argument list. Later logic to detect out-of-order
arguments and produce relabelling fixes didn't account for them though.
This improves several diagnostics for mislabelled call arguments in the
existing tests.
If a tuple is passed as the only argument to a function that takes two unnamed arguments, we try to diagnose the missing argument label. However, in the old diagnose code we didn’t distinguish between non-existing arguments and arguments without labels; both behaved the same.
Thus, the missing second argument in the function call would line up with the empty second argument label, not producing a diagnostic, but hitting an assertion later on.
Distinguish between the two to fix the issue.
Fixes rdar://64319340
Current logic fix-it didn't account for the first argument being re-ordered.
The start position for the first argument should always be the next token
after left paren denoting a start of the argument list.
Resolves: rdar://problem/70764991
The change to the forward-scanning rule regressed some diagnostics,
because we no longer generated the special "trailing closure mismatch"
diagnostic. Reinstate the special-case "trailing closure mismatch"
diagnostic, but this time do so as part of the normal argument
mismatch diagnostics so it is based on type information.
While here, clean up the handling of missing-argument diagnostics to
deal with (multiple) trailing closures properly, so that we can (e.g)
suggest adding a new labeled trailing closure at the end, rather than
producing nonsensical Fix-Its.
And, note that SR-12291 is broken (again) by the forward-scan matching
rules.
To preserve subtype relationship between element types of a collection
passed as an argument to a parameter represented by another collection
type let's extend opening of the collection types to be done for arguments
to @autoclosure parameters as well because implicit closure is transparent
to the caller.
Resolves: [SR-13135](https://bugs.swift.org/browse/SR-13135)
Resolves: rdar://problem/65088975
