@brson: r? [please ignore the other one that was accidentally based off master due to back-button-bugs in github.com]
My goal is to resolve the question of whether we want to encourage (by example) consistent use of pub to make identifiers publicly-accessible, even in syntax extensions. (If people don't want that, then we can just let this pull request die.)
This is part one of two. Part two, whose contents should be clear from the FIXME's in this commit, would land after this gets incorporated into a snapshot.
(The eventual goal is to address issue #6009 , which was implied by my choice of branch name, but not mentioned in the pull request, so github did not notice it.)
Also fixed the docstring on `TC_ONCE_CLOSURE` (was accidentally the same as `TC_MUTABLE`) and shifted the `TC_EMPTY_ENUM` bit left by one since whatever previously used that bit has been removed.
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);
~~~
