I'd really like to be able to do something like
struct MapChain<'next, K, V> {
info: BlockInfo,
map: HashMap<K, V>,
next: Option<&'next mut MapChain<'next, K, V>
}
but I can't get the lifetimes to work out.
Right now on linux, an empty executable with LTO still depends on librt becaues
of the clock_gettime function in rust_builtin.o, but this commit moves this
dependency into a rust function which is subject to elimination via LTO.
At the same time, this also drops libstd's dependency on librt on unices that
are not OSX because the library is only used by extra::time (and now the
dependency is listed in that module instead).
Right now if you have concurrent builds of two libraries in the same directory
(such as rustc's bootstrapping process), it's possible that two libraries will
stomp over each others' metadata, producing corrupt rlibs.
By placing the metadata file in a tempdir we're guranteed to not conflict with
ay other builds happening concurrently. Normally this isn't a problem because
output filenames are scoped to the name of the crate, but metadata is special in
that it has the same name across all crates.
Currently any line starting with `#` is filtered from the output,
including line like `#[deriving]`; this patch makes it so lines are only
filtered when followed by a space similar to the current behaviour of
the tutorial/manual tester.
* Pass `&ExtCtxt` instead of `@ExtCtxt`.
* Stop passing duplicate parameters around in `expand`.
* Make `ast_fold` methods take `&mut self`.
After these, it should be possible to remove the `@mut` boxes from `ExtCtxt` altogether, though #11167 is doing some of that so I'm holding off on that for now. This will probably conflict with that PR, so I'm guessing that one will have to be rebased on top of the other.
r? @pcwalton
Currently any line starting with `#` is filtered from the output,
including line like `#[deriving]`; this patch makes it so lines are only
filtered when followed by a space similar to the current behaviour of
the tutorial/manual tester.
Turns out when you grab an OS mutex, you need to be careful about when and where
things are scheduled!
I've confirmed that I could fairly reliably get a deadlock (1 in 100 times ish) before this, and I cannot get a deadlock after this (after 1000+ runs).
Closes#11200
Some people have requested this, and I think it's quite useful to have
documentation for the compiler libraries. libnative and libgreen are
self-explanatory I think.
