Escapingness is a property of the type of a value, not a property of a function
parameter. Having it as a separate parameter flag just meant one more piece of
state that could get out of sync and cause weird problems.
Instead, always look at the noescape bit in a function type as the canonical
source of truth.
This does mean that '@escaping' is now printed in a few diagnostics where it was
not printed before; we can investigate these as separate issues, but it is
correct to print it there because the function types in question are, in fact,
escaping.
Fixes <https://bugs.swift.org/browse/SR-10256>, <rdar://problem/49522774>.
Back when SE-0110 was implemented we decided that passing a function value
taking multiple parameters would be allowed where a function value taking
a single tuple argument was expected.
Due to quirks in the old function type representation, the "splat" in the
other direction sometimes worked too. When we redid the function type
representation we added a simulation of the old quirk for -swift-version 4
mode.
However this simulation was itself problematic because it only worked when
the function value being passed was a non-overloaded declaration reference.
Slightly broaden the hack to the overloaded case, to prevent user
confusion when adding or removing overloads.
This makes diagnostics more verbose and accurate, because
it's possible to distinguish how many parameters there are
based on the message itself.
Also there are multiple diagnostic messages in a format of
`<descriptive-kind> <decl-name> ...` that get printed as
e.g. `subscript 'subscript'` if empty labels are omitted.
This patch adds warning for redundant access-level modifiers
used in an extension. It also refines the diagnostics of
access_control_ext_member_more issues, in case the fixit
could suggest redundant modifiers.
Resolves: SR-8453.
From the perspective of the compiler implementation, they're elements. But users will think of these as cases—and many diagnostics already refer to these as enum cases.
That hack resulted in already matching argument and parameter to end
up not matching in this case.
Fixes https://bugs.swift.org/browse/SR-7191
and rdar://problem/38798063
Move the existing test into Compatibility/tuple_arguments_4.swift.
Move the Swift 3 test, Compatibility/tuple_arguments.swift, into
Compatibility/tuple_arguments_4.swift.
Add a couple new tests to each file to capture what we do in each
mode.
Overall this doesn't seem like the most satisfying approach for
covering compatibility testing in our standard commit testing, but
it's all we've got at the moment.
