Inconsistency with 1-tuples

[catamorphism]

We allow patterns on 1-tuples, at least in theory:

match z {
    (x,) => { ... }
}

The parser code for 1-tuple patterns didn't quite work as intended, and I fixed that. But then I ran into the problem that I couldn't write a test because there's no way to write a 1-tuple literal or type ((x) gets parsed as x).

Is this intentional? It seems like if we're going to allow 1-tuple patterns, we should also allow 1-tuple terms (perhaps with the same (x,) syntax?)

This came up, as you might expect, because of macros: I was trying to replace structural records with tuples in the pipes code (that seemed easier than dynamically generating new struct type names) and I ran into the parser problem, which I was able to fix but not test.

[catamorphism]

I am going to go ahead and implement 1-tuple literals in a branch (with the same syntax as patterns) and see how ugly it ends up making things.

[graydon]

1-tuples strike me as a bit silly; if it's solvable inside the macro I'd prefer that. Otherwise I won't lose a ton of sleep over 1-tuples. The biggest risk to me seems to be in the grammar, concerning potential ambiguity of commas, and I imagine any such risks are already present.

[catamorphism]

Still to-do: to_str and eq impls for 1-tuples (needs a snapshot). I guess we might as well...

[catamorphism]

Also needing a snapshot: fix repr, and add a test to the exact_repr tests.

[graydon]

looks like there is a test in for this now; is it done?

[graydon]

non-critical for 0.6, de-milestoning

[catamorphism]

It's not done yet -- there were some parts waiting for a snapshot, which has happened now.

[catamorphism]

Done, pending bors (#5547)

[catamorphism]

Done in 5011d05