It seems that relatively new code uses `Foo::new()` instead of `Foo()` so I wrote a patch to migrate some structs to the former style.
Is it a right direction? If there are any guidelines not to use new()-style, could you add them to the [style guide](https://github.com/omasanori/rust/wiki/Note-style-guide)?
The truncation needs to be done in the console logger in order
to catch all the logging output, and because truncation only matters
when outputting to the console.
Update the arm linux support some more. We had a previous patch for the RasberryPi. This adds a new target `arm-unknown-linux-gnueabi` for more general arm linux support.
Build/Host machine: x86_64 Debian testing (jessie) with the `gcc-4.4-arm-linux-gnueabi` package
Tested on targets:
- TS-7800 Feroceon (ARMv5TEJ) running Debian 7.0 wheezy
- Beaglebone black (ARMv7) running Angstrom GNU/Linux v2012.12
- rustc flags: `--target=arm-unknown-linux-gnueabi --linker=arm-linux-gnueabi-gcc`
- Samsung Galaxy S II (to make sure android still works)
- rustc flags: `--target=arm-linux-androideabi --android-cross-path=[path to standalone toolchain]`
Since not all arm devices (i.e. afaik anything older than armv6 like the ts-7800 i tested on) supported getting the tls address via the `mrc` instruction, I made it also try via the magic address the kernel maps into the address space (0xFFFF0FF0). One or the other should work (and on android it seems like both work).
Also fixes a bug where rustc would always try to invoke the android assembler for any kind of arm target.
The compiler-generated dtor for DList recurses deeply to drop Nodes.
For big lists this can overflow the stack.
This is a problem for the new scheduler, where split stacks are not implemented.
Thanks @blake2-ppc
When strings lose their trailing null, this pattern will become dangerous:
let foo = "bar";
let foo_ptr: *u8 = &foo[0];
Instead we should use c_strs to handle this correctly.
Every time run_sched_once performs a 'scheduling action' it needs to guarantee
that it runs at least one more time, so enqueue another run_sched_once callback.
The primary reason it needs to do this is because not all async callbacks
are guaranteed to run, it's only guaranteed that *a* callback will run after
enqueing one - some may get dropped.
At the moment this means we wastefully create lots of callbacks to ensure that
there will *definitely* be a callback queued up to continue running the scheduler.
The logic really needs to be tightened up here.
WIth this patch `RUSTFLAGS='--cfg unicode' make check"` passed successfully.
* Why doesn't `#[link_name="icuuc"]` make libextra to link against libicuuc.so?
* In `extra::unicode::tests`, `use unicode; unicode::is_foo('a')` failed but `use unicode::*; is_foo('a')` succeeded. Is it right?
* LLVM now has a C interface to LLVMBuildAtomicRMW
* The exception handling support for the JIT seems to have been dropped
* Various interfaces have been added or headers have changed