r?

Previously check always succeeded because struct type was derived from the matched expression, not the matched pattern.

Fix #4849.

Closes #4924

There are some more `Load` calls that could use this, so it's not completely done yet.

It looks like the type for the whole pattern wasn't being written back, so when privacy tried to look it up everything died.

Closes #4924

As far as I can tell, the only reason run-pass/type-use-i1-versus-i8
is trying to do a read is because that code was left over from the
original program the issue was found in.  When that test is run as
part of check-fast, and apparently only in that case, the test blocks
indefinitely, which is bad.

This patch series is doing a couple things with the ultimate goal of removing `#[allow(vecs_implicitly_copyable)]`, although I'm not quite there yet. The main change is passing around `@~str`s in most places, and using `ref`s in others. As far as I could tell, there are no performance changes with these patches, and all the tests pass on my mac.

Actually a trivial fix. Fixes the issue #4935.

Previously check always succeeded because struct type was derived from
the matched expression, not the matched pattern.

r? @graydon - This is for greater uniformity (for example, macros that generate
tuples). rustc already supported 1-tuple patterns, but there was no
way to construct a 1-tuple term.

@graydon , as far as your comment on #4898 - it did turn out to be solvable inside the macro (since @luqmana already fixed it using structs instead), but I still think it's a good idea to allow 1-tuples, for uniformity. I don't think anyone is likely to trip over it, and I'm not too worried that it changes the amount of ambiguity.