This is some stuff which seemed to be missing to me (though I haven't read everything yet so hope I haven't missed the relevant section).
A similar addition for borrowing handles is needed, but #5720 stumped me.
Comments welcome.
In my WIP on rustpkg, I was calling driver code that calls
LLVMRustWriteOutputFile more than once. This was making LLVM
unhappy, since that function has code that initializes the
command-line options for LLVM, and I guess you can't do that more
than once. So, check if they've already been initialized.
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.
