Even more of `core::run` could be rust-ified -- I believe that access to the C extern environ can be done with rust now. I did not do this because some special casing is needed for OSX and I don't have a mac I can test with.
I think this will also fix#6096.
Recent demoding makes the visitor glue leak. It hasn't shown up in tests
because the box annihilator deletes the leaked boxes. This affects the
new scheduler though which does not yet have a box annihilator.
I don't think there's any great way to test this besides setting up
a task that doesn't run the box annihilator and I don't know that that's
a capability we want tasks to have.
Lots of linking arguments need to be passed as -Wl,--foo so giving the
comma meaning at the rustc layer makes those flags impossible to pass.
Multiple arguments can now be passed from a shell by quoting the
argument: --link-args='-lfoo -Wl,--as-needed'.
I don't know how one would write a separate test for this sort of thing. Building the compiler, and `make check` worked, which should mean I didn't screw anything.
- it is now cross platform, instead of just unix
- it now avoids sleeping (fixing issue #6156)
- it now calls force_destroy() when force = true (was a bug)
Lots of linking arguments need to be passed as -Wl,--foo so giving the
comma meaning at the rustc layer makes those flags impossible to pass.
Multiple arguments can now be passed from a shell by quoting the
argument: --link-args='-lfoo -Wl,--as-needed'.
This adds #[inline] to many very common string routines (e.g. `len`).
It also rewrites `repeat` to not use `+=` and make it O(n) rather than O(n^2), and also concat/connect(_slices) to reduce the overhead of reallocations, and constantly `set_len`ing (etc) in `push_str`. (The added complexity might not be worth the 20% speedup though.)
This has happened to two people trying to get Rust working on other platforms. Since it won't compile either way, make a nicer message for it (which will also point them straight to the correct file).
I have noticed these comments scattered across the codebase. They appear to be vestigial Emacs formatting settings and they don't appear in newer files. For the sake of consistency it's probably best to remove them.
this could probably use expansion - it just uses all of the default
options, which is usually what we want, but not always. maybe add a
separate function that takes more options?
