This approach, suggested by Xiaodi Wu, provides better source
compatibility for existing Swift code, by breaking ties in favor of the
existing Swift semantics. Each time the backward-scan rule is needed
(and differs from the forward-scan result), we will produce a warning
+ Fix-It to prepare for Swift 6 where the backward rule can be
removed.
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.
The current approach for type-checking single trailing closures
is to scan backwards from the end of the parameter list, looking
for something that can be passed a closure. This generalizes that
to perform label-matching in reverse on any later trailing closures,
then pick up from that point when trying to place the unlabeled
trailing closure.
The current approach is really not a good language rule, but changing
it as much as we'd really like will require evolution approval and a
source break, so we have to be cautious.
