@thestinger r?
~~The 2 `_unlimited` functions are marked `unsafe` since they may not terminate.~~
The `state` fields of the `Unfoldr` and `Scan` iterators are public, since being able to access the final state after the iteration has finished seems reasonable/possibly useful.
~~Lastly, I converted the tests to use `.to_vec`, which halves the amount of code for them, but it means that a `.transform(|x| *x)` call is required on each iterator.~~
(removed the 2 commits with `to_vec` and `foldl`.)
This allows one to write
```rust
let x = function_with_complicated_return_type();
let size = size_of_val(&x);
```
instead of
```rust
let x = function_with_complicated_return_type();
let size = size_of::<ComplicatedReturnType<Foo, Bar>>();
```
This closes#4364. I came into rust after modes had begun to be phased out, so I'm not exactly sure what they all did. My strategy was basically to turn on the compilation warnings and then when everything compiles and passes all the tests it's all good.
In most cases, I just dropped the mode, but in others I converted things to use `&` pointers when otherwise a move would happen.
This depends on #5963. When running the tests, everything passed except for a few compile-fail tests. These tests leaked memory, causing the task to abort differently. By suppressing the ICE from #5963, no leaks happen and the tests all pass. I would have looked into where the leaks were coming from, but I wasn't sure where or how to debug them (I found `RUSTRT_TRACK_ALLOCATIONS`, but it wasn't all that useful).
I ran across this when working on some other changes, and it looked like it wasn't too hard to "fix". I'm not very familiar with this code, but it looks like if an error was already generated there's no need to generate and ICE as well when parts of the program can just be ignored for more incorrectness.
This switches the unicode functions in core to use static character-range tables and a binary search helper rather than open-coded switch statements. It adds about 50k of read only data to the libcore binary but cuts out a similar amount of compiled IR. Would have done it this way in the first place but we didn't have structured statics for a long time.
vec::windowed fails if given window size is greater than vector length + 1.
```rust
for vec::windowed(7, &[1,2,3,4,5,6]) |vs| { fail!(); } // => do nothing
for vec::windowed(8, &[1,2,3,4,5,6]) |vs| { fail!(); } // => assertion failure in vec::slice
```
r?
This pull request is a grab bag of work on the new scheduler.
The most important commit here is where I [outline](https://github.com/brson/rust/blob/io/src/libcore/rt/io/mod.rs) a fairly complete I/O API, based on `Reader` and `Writer` types, as in the current `core::io` module. I've organized this version into a number of modules with declarations for Files, TCP, UDP, Unix sockets, blocking/non-blocking implementations, memory buffers, compression adapters. I'm trying to get this into shape to present on the mailing list.
This branch also wires up `spawn` to the new scheduler, and simplifies the core scheduler operations.
It will check which scheduler it is running under and create the
correct type of task as appropriate. Most options aren't supported
but basic spawning works.
This adds debugging symbol generation for boxes, bare functions, vectors, and strings, along with a tests for boxes and vectors.
Note that gdb will see them as their actual compiled representation with the refcount, tydesc, etc. fields, so if `b` refers to box, `b->boxed` will refer to its value. Also, since you seem to use the [C struct hack](http://c-faq.com/struct/structhack.html) for dynamic vectors, you won't be able to print out the whole vector at once, only one element at a time by indexing specific elements.
