bare function store (which is not in fact a kind of value) but rather
ty::TraitRef. Removes many uses of fail!() and other telltale signs of
type-semantic mismatch.
cc #4183 (not a fix, but related)
Because the PTHREAD_STACK_MIN of my system is larger than default size, I add the stack_sz check to prevent assertion failure.
Besides, libuv has to be modified because some flags are different from other targets. Instead of using hardcoded numbers, I change them to predefined symbols.
By the way, the toolchain I used is http://www.mentor.com/embedded-software/sourcery-tools/sourcery-codebench/editions/lite-edition/mips-gnu-linux
libuv patch: http://people.cs.nctu.edu.tw/~jyyou/rust/mips-uv.patch
Below is the current test result.
* core test
stackwalk tests can cause segfault so I ignored them.
```
failures:
io::tests::test_read_be_int_n
io::tests::test_read_buffer_big_enough
io::tests::test_read_f32
io::tests::test_read_write_be
io::tests::test_read_write_f32
io::tests::test_read_write_le
io::tests::test_simple
io::tests::test_write_empty
rand::tests::rng_seeded_custom_seed2
unstable::uvll::test::test_uv_ll_struct_size_addrinfo
unstable::uvll::test::test_uv_ll_struct_size_uv_timer_t
result: FAILED. 596 passed; 11 failed; 49 ignored
```
* std test:
```
failures:
time::tests::run_tests
result: FAILED. 330 passed; 1 failed; 21 ignored
```
The sentence "Remember that `(float, float)` is a tuple of two floats"
sounds like you've already read a section on tuples, but that section
comes later. Changing it to "Assuming that ..." makes it more about
taking the writer's word that the syntax is how tuples are defined.
Existing rust code decides main name by host environment of rustc.
I think it should be chosen by build target.
This patch is also removing one of the android hacks that is not necessary any longer(I think it was not necessary from the first).
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?
The sentence "Remember that `(float, float)` is a tuple of two floats"
sounds like you've already read a section on tuples, but that section
comes later. Changing it to "Assuming that ..." makes it more about
taking the writer's word that the syntax is how tuples are defined.
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.
