[migrator] Add an AST pass to handle tuple mismatches

[akyrtzi]

Migrates code that compiles fine in Swift 3 but breaks in Swift 4 due to
changes in how the typechecker handles tuple arguments.

[akyrtzi]

@swift-ci test and merge

[slavapestov]

I'm not sure I understand the transformations here. You're handling two specific cases which no doubt came up in some projects you were migrating but they're very narrow.

I doubt a lot of code defines functions written as func foo(_: ()) or func foo(_: ((...)) -> ()). A more common example would be a generic function struct Result<T> { func foo(_: T) } with T=(Int, Int). Previously you could call it like Result.foo(1, 2) now it must be a Result.foo((1, 2)).

However it seems it would be hard to reason about generic substitutions in the migrator.

This transformation should be done via fixits in the type checker and not a migrator pass. @xedin is working on such fixits, so please do not add this pass.

[akyrtzi]

In general, compiler fixits are not a robust solution for a migration workflow; an error will make code invalid which will prevent type checking, which may mask other errors and not provide fixits for them, we had plenty of such experience in the past. It's good to have compiler fixits in general and as a fallback, but the migrator passes are more robust.
In the end the code will build after conversion which is all that matters.

[slavapestov]

That doesn't address my original concern that the transformations here are not really the right ones we need for SE-0110.

[akyrtzi]

Your example does not compile in Swift 3. What compiles is Result<()>().foo(), and the migrator pass does change that to Result<()>().foo(()). And we did see similar example in a project, see the enum case in the test file.

[slavapestov]

Let's discuss in person. I implemented SE-0110 and I don't think it makes sense for the migrator to be performing these transformations.