Both expm1 and ln1p have been renamed to exp_m1 and ln_1p in order to be consistent with the underscore usage elsewhere.
The exp_m1 method is used for increased accuracy when doing floating point calculations, so this has been moved from the more general 'Exponential' trait into 'Float'.
Closes#5392 and #5393
I implemented the pop/swap methods for TrieMap/TreeMap/SmallIntMap, and I also updated all of them such that pop isn't just a remove/insert, but rather it's all done in one operation.
One thing I did notice is that with default methods it'd be really nice to define `insert` and `remove` in terms of `pop` and `swap` (or vice versa, just to have them available).
To provide a reference counted pointer type with deterministic
destruction once managed boxes are switched over to a garbage
collector. Unlike managed boxes, these can be moved instead of just
copied/cloned which is helpful for avoiding reference counts.
Needs #5601 to be fixed in order for safety to be provided without the current ugly workaround of making the pointers contain `Option<@()>` and `Option<@mut ()>` (which are just set to `None`).
@brson: r?
I just removed `pub mod` from `core.rc` and then got everything to compile again. One thing I'm worried about is an import like this:
```rust
use a;
use a::b;
mod a {
pub type b = int;
}
mod b {
use a; // bad
use a::b; // good
}
```
I'm not sure if `use a::b` being valid is a bug or intended behavior (same question about `use a`). If it's intended behavior, then I got around these modules not being public by only importing the specific members that are necessary. Otherwise that probably needs an open issue.
This rather sprawling branch refactors the borrow checker and much of the region code, addressing a number of outstanding issues. I will close them manually after validating that there are test cases for each one, but here is a (probably partial) list:
- #4903: Flow sensitivity
- #3387: Moves in overloaded operators
- #3850: Region granularity
- #4666: Odd loaning errors
- #6021: borrow check errors with hashmaps
- #5910: @mut broken
cc #5047
(take 5)
To provide a reference counted pointer type with deterministic
destruction once managed boxes are switched over to a garbage
collector. Unlike managed boxes, these can be moved instead of just
copied/cloned which is helpful for avoiding reference counts.
Support #5297
install.mk : install-runtime-target added for conveneice
automatically push runtime library to android device
test.mk : expanded to support android test automation with adb
compiletest : expanded to support android test automation with adb
Moving the trait into `core` allows it to be added to the `num::Float` trait.
I have also added and `assert_approx_eq!` macro. This is useful fo making approximate assertions on types that implement the `ApproxEq` trait.
Examples:
~~~rust
// using the default epsilon value
assert_approx_eq!(1.0000001f, 1.0f);
// using a custom epsilon value
assert_approx_eq!(1.000001f, 1.0f, 1.0e-5);
// fails with: "left: 1.00001 does not approximately equal right: 1"
assert_approx_eq!(1.00001f, 1.0f);
~~~
transitional patch to resolve compile/link failure on android
after #6161 landed, I've encountered below errors since android does not support glob in libc.
/opt/ndk_standalone/bin/../lib/gcc/arm-linux-androideabi/4.6/../../../../arm-linux-androideabi/bin/ld: /home/yichoi/rust_work/build/x86_64-unknown-linux-gnu/stage1/lib/rustc/arm-linux-androideabi/lib/libcore-c3ca5d77d81b46c1-0.7-pre.so: error: undefined reference to 'glob'
/opt/ndk_standalone/bin/../lib/gcc/arm-linux-androideabi/4.6/../../../../arm-linux-androideabi/bin/ld: /home/yichoi/rust_work/build/x86_64-unknown-linux-gnu/stage1/lib/rustc/arm-linux-androideabi/lib/libcore-c3ca5d77d81b46c1-0.7-pre.so: error: undefined reference to 'globfre
Since android does not have `glob.h`, `glob_t` definition comes from
https://groups.google.com/forum/?fromgroups=#!topic/android-ndk/vSH6MWPD0Vk#6100 should be resolved.
In commit d7f5e43 "core::rt: Add the local heap to newsched tasks",
local_malloc and local_free have become rather big and their forced
inlining causes quite a bit of code bloat. Compile times for crates
affected by the bloat (e.g. rustc) improve, while others (e.g. libstd)
seem to be unaffected, so I guess the inlining doesn't gain us much.
Sizes:
```
| librustc | libsytax
---------------|–-----------|------------
with inlining | 18,547,824 | 7,110,848
w/o inlining | 15,092,040 | 5,518,608
