Currently error messages say ``mismatched types: expected `uint` but found `[uint * 10]` (expected uint but found vector)`` rather than `[uint, .. 10]`.
r? @brson 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.
This adds two generic data types, `Ratio` and `Cmplx` (and some aliases for useful instances, e.g. `Ratio<int>` and `Cmplx<f64>`), and basic arithmetic support, as well as `.to_str` (for both) and `.from_str` (for rational).
The complex number implementation doesn't solve #1284 other than getting something into the libraries, specifically it doesn't even try to address C interop. If the complex part of this gets merged, maybe it's worth closing that issue and reopening more specific issue(s) about the failings.
The implementations can be fleshed out when the numeric traits stabilise (and trait inheritance works).
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.
