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.
Closes#3549
The issue report has some reasoning, but I'd like to add that I don't think managed pointers belong in core. It's *possible* to write a safe doubly-linked list on top of `unsafe`, but it would be much more limited and I don't think there's much of a use case - it would lose a lot of flexibility. You're probably better off using a vector, hash table, tree, heap or ring buffer in almost every case.
