Fix exponential type checking of tuple literals.

[rudkx]

This fixes two easy cases where we would go exponential in type
checking tuple literals.

Instead of generating a conversion to a single type variable (which
results in one large constraint system), we generate a conversion ot
the same type that appears in the initializer expression (which for
tuples is a tuple type, which naturally splits the constraint system).

I experimented with trying to generalize this further, but ran into
problems getting it working, so for now this will have to do.

Fixes rdar://problem/20233198.

[rudkx]

@swift-ci Please smoke test

[xedin]

Nice! Very easy win

[rudkx]

@swift-ci Please smoke test

[rudkx]

Oops, need to move the fixed perf test over as well.

[rudkx]

@swift-ci Please smoke test

[rudkx]

@swift-ci Please smoke test Linux platform

[rudkx]

@swift-ci Please clean smoke test Linux platform

[rudkx]

@swift-ci Please test source compatibility

[rudkx]

@swift-ci Please test source compatibility

[rudkx]

Source compat failure is also happening without my changes.

[davezarzycki]

Hi @rudkx – A question for you about the changes to the PatternKind::Named case in CSGen.cpp. Is it fair to say that isWeak really means "requires a wrapped type"? In the case of 'weak', that means Optional, of course. I'm asking because I have a branch with two additional ReferenceOwnership enumerations, and I'm trying to understand why 'weak' is special, but not 'unowned' or 'unmanaged'. Thanks!

[rudkx]

As I understand it, weak variables must be optional because they are reference types, but do not form strong references; i.e. the object they refer to can be released as a result of all the strong references going out of scope (or being released). When that happens, they are nil'ed out.

[davezarzycki]

I understand how weak references work. Can you just review #15540 instead? Thanks! :-)