This pull request removes some mut-fields from at_vec, str, vec, unstable, and cell. Sadly in case of Cell this required using either transmute_mut (2 instances) or changing the interface. I chose the former. Perhaps it would be a good idea to merge Cell and Option, and take that opportunity to change the interface to use '&mut self' instead of '&self' (which would enable removing the transmutations) for take and put_back.
r?
This naming is free now that `oldmap` has finally been removed, so this is a search-and-replace to take advantage of that. It might as well be called `HashMap` instead of being named after the specific implementation, since there's only one.
SipHash distributes keys so well that I don't think there will ever be much need to use anything but a simple hash table with open addressing. If there *is* a better way to do it, it will probably be better in all cases and can just be the default implementation.
A cuckoo-hashing implementation combining a weaker hash with SipHash could be useful, but that won't be as general purpose - you would need to write a separate fast hash function specialized for the type to really take advantage of it (like taking a page from libstdc++/libc++ and just using the integer value as the "hash"). I think a more specific naming for a truly alternative implementation like that would be fine, with the nice naming reserved for the general purpose container.
Changes the parser to parse all streams into token-trees before hitting the parser proper, in preparation for hygiene. As an added bonus, it appears to speed up the parser (albeit by a totally imperceptible 1%).
Also, many comments in the parser.
Also, field renaming in token-trees (readme->forest, cur->stack).
This implements the clone interface for tuples and adds a test to match. The implementation is only on tuples that have elements that are themselves clone-able. This should allow for `#[deriving(Clone)] on nominal types that contain tuples somewhere.
As per https://github.com/mozilla/rust/wiki/Note-wanted-libraries.
Iterates over lines in a series of files, e.g. a basic `cat`
```rust
use std::fileinput;
fn main() {
for fileinput::input |line| {
io::println(line);
}
}
```
The API is essentially a subset of [Python's fileinput module](http://docs.python.org/3.3/library/fileinput.html), although the lack of default arguments and global mutable state means that there are extra functions to handle a few different cases (files from command line arguments, files from a vector, accessing current filename/line number).
A few points that possibly require adjustment:
- Most functions take vectors of `Path` (well, `Option<Path>`) rather than just `~str`, since this seems safer, and allows finer control without the number of different functions/methods increasing exponentially.
- `pathify` has a stupid name.
- I'm not quite sure how to mock tests that require external files: the tests in `libcore/io.rs` seem to indicate using a `tmp` subdirectory, so that's what I did, but I can't reliably build rust on this computer to test (sorry! although I have run the tests in just `fileinput.rs` after creating `./tmp/` manually).
- The documentation I've written seems pretty crappy and not particularly clear.
- Only UTF8 files are supported.
When I submitted #5659, it apparently caused some test failures. Then, because I left it in my incoming rather than making a new branch, I deleted my commit.
Let's try this again, this time, with its own branch so that I don't screw it up.
r?
This pull request completely removes Mut<T> and the associated file (libcore/mutable.rs). Some minor changes were made to workcache (libstd/workcache.rs) as it was using Mut.
r?
It seems nobody can figure out whether this is _supposed to_ make a difference anymore, and in testing it seems to work either way, so I removed it. One less alarming warning during a fresh build.
