Tuple conversion implementation appears confused

[gafter]

The tuple conversion implementation appears either confused or confusing. A method

        private BoundExpression CreateTupleConversion(CSharpSyntaxNode syntax, BoundTupleLiteral sourceTuple, Conversion conversion, bool isCast, TypeSymbol destination, DiagnosticBag diagnostics)

results in a bound node that does not have the destination type (but instead a type that is a combination of the destination type with names from the source tuple). I don't think that's right.

[VSadov]

That is for cases like

( (long a, long b) ) ( c: 1, d: 2 );
The literal is target-typed to (long c, long d), because target-typing of elements affects only types, not names. I think that was the idea when we discussed this. We can change that.

Then there is a conversion node that identity-converts to (long a, long b).

The result is (long a, long b), the conversion is not confused.
It just goes through two steps - target typing of the literal and then name-conversion.

Since semantic info exposes the top conversion, it will look as
IdentityConversion: (long c, long d) --> (long a, long b)

[AlekseyTs]

If that code survives, we need to decide what to do with location for the tuple symbol.

[VSadov]

I think location of a thing named "c" should be where we have "c" introduced in the source.
The symbol for (long c, long d) will have location "( c: 1, d: 2 );"

The natural type (int c, int d) would also have that location, but I do not think the type will be observable in APIs, so that should not be confusing.

[VSadov]

WithElementNames should probably take locations in addition to names.

Original locations are almost certainly incorrect when names are substituted. - How can it be in the same place when names are different?