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.
```
These commits take the old bitv implementation and modernize it with an explicit self, some minor touchups, and using what I think is some more recent patterns (like `::new` instead of `Type()`).
Additionally, this adds an implementation of `container::Set` on top of a bit vector to have as a set of `uint`s. I initially tried to parameterize the type for the set to be `T: NumCast` but I was hitting build problems in stage0 which I think means that it's not in a snapshot yet, so it's just hardcoded as a set of `uint`s now. In the future perhaps it could be parameterized. I'm not sure if it would really add anything, though, so maybe it's nicer to be hardcoded anyway.
I also added some extra methods to do normal bit vector operations on the set in-place, but these aren't a part of the `Set` trait right now. I haven't benchmarked any of these operations just yet, but I imagine that there's quite a lot of room for optimization here and there.
Removes the last use of structural records in the pipes extension and with that, libcore has no more structural records.
Also, explicit-self-ification.
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.
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.
Consts of such enums are aligned correctly, so we could either misalign
them to match the type_of, or fix the type_of. The latter seems like a
better idea.
