Roll back a portion of SE-0110

[rudkx]

As described in:

https://lists.swift.org/pipermail/swift-evolution-announce/2017-June/000386.html

Specifically allow an N-ary argument function to be passed as an
argument in a place where a function of a single N-tuple is expected.

Fixes: rdar://problem/32875953

[rudkx]

@swift-ci Please smoke test

[rudkx]

@swift-ci Please test source compatibility

[rudkx]

@slavapestov @rjmccall I still need to make another pass over the tests to see if I need to add additional tests, see if the behavior when generics are involved makes sense, and fixup a couple migrator tests, but so far this seems like a reasonable way to allow a very narrow exception to get back some of the usability of closures that accept multiple arguments being used in places that expect to call closures that except a tuple.

[rudkx]

@bitjammer Have you seen this assertion failure in the migrator code before? I would expect that some errors & fixits would no longer be present as a result of my changes, but not that the migrator code would run into assertions as a result.

Command Output (stderr):
--
/Users/buildnode/jenkins/workspace/swift-PR-osx-smoke-test/branch-master/swift/test/Migrator/Inputs/never_compiles_safely_exits_breaking_code.swift:1:15: warning: when calling this function in Swift 4 or later, you must pass a '()' tuple; did you mean for the input type to be '()'?
func foo(_ f: (Void) -> ()) {}
              ^~~~~~
              ()
Assertion failed: (FD >= 0 && "File not yet open!"), function preferred_buffer_size, file /Users/buildnode/jenkins/workspace/swift-PR-osx-smoke-test/branch-master/llvm/lib/Support/raw_ostream.cpp, line 624.

[bitjammer]

Yes, that means that (usually) we forgot to make the destination directory for the migrated swift or remap file. I'm guessing you made something compile that didn't before? That's why the test is continuing on into the migrator and emitting migrated contents. I think that test will need to be updated to some other code that can't compile (and doesn't have proactive fix-its that the migrator can try to pick up before actually doing the migration).

[bitjammer]

To be clear, the test is not supposed to rm -rf/mkdir because it's not supposed to make it to emitted migrated stuff. It just needs to be updating to something else that still doesn't compile.

[rudkx]

@swift-ci Please smoke test

[rudkx]

@swift-ci Please test source compatibility

[rudkx]

@swift-ci Please test source compatibility

[slavapestov]

I'd rather we did this by going back to the Swift 3.1 behavior instead of adding new unproven semantics.

[slavapestov]

Something like this: #10257

[rudkx]

@bitjammer David, my change here backs out 726adfb because it no longer seems necessary with this update to the type checker since we no longer emit that fixit for these cases. I also updated never_compiles_safely_exits_breaking_code.swift as a result as well, but I think that was from a different commit.

Do these look okay?

[rudkx]

@swift-ci Please test source compatibility

[bitjammer]

As long as you feel that the diagnostic won't come up in other cases which would be surprising during migration, it's fine by me if you want to remove that filter.

[rudkx]

@swift-ci Please test source compatibility

[rudkx]

@swift-ci Please test source compatibility

[rudkx]

@swift-ci Please smoke test

[rudkx]

@swift-ci Please smoke test