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.
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.
This implements a rust tool similar to go's go tool. It acts as a central hub for the tools rustc, rustdoc, rustpkg, rusti, and also provides shortcuts for directly compiling and running a source file either as a normal or a test executable. Default usage message:
```
The rust tool is a convenience for managing rust source code.
It acts as a shortcut for programs of the rust tool chain.
Usage: rust <command> [arguments]
The commands are:
build compile rust source files
run build a executable, and run it
test build a test executable, and run it
doc generate documentation from doc comments
pkg download, build, install rust packages
sketch run a rust interpreter
help show detailed usage of a command
Use "rust help <command>" for more information about a command.
```
