Buffer unix and lock windows to prevent message interleaving
When cargo does a build on multiple processes, multiple crates may error at the same time. If this happens, currently you'll see interleaving of the error messages, which makes for an unreadable message.
Example:
```
--> --> src/bin/multithread-unix.rs:16:35src/bin/singlethread.rs:16:24
||
1616 | | Server::new(&addr).workers(8). Server::new(&addr).serveserve(|r: Request| {(|r: Request| {
| | ^^^^^^^^^^ expected struct `std::io::Error`, found () expected struct `std::io::Error`, found ()
||
= = notenote: expected type `std::io::Error`: expected type `std::io::Error`
= = notenote: found type `()`: found type `()`
= = notenote: required because of the requirements on the impl of `futures_minihttp::Service<futures_minihttp::Request, futures_minihttp::Response>` for `[closure@src/bin/multithread-unix.rs:16:41: 22:6]`: required because of the requirements on the impl of `futures_minihttp::Service<futures_minihttp::Request, futures_minihttp::Response>` for `[closure@src/bin/singlethread.rs:16:30: 22:6]`
error: aborting due to previous error
error: aborting due to previous error
```
This patch uses two techniques to prevent this interleaving. On Unix systems, since they use the text-based ANSI protocol for coloring, we can safely buffer up whole messages before we emit. This PR does this buffering, and emits the whole message at once.
On Windows, term must use the Windows terminal API to color the output. This disallows us from using the same buffering technique. Instead, here we grab a Windows mutex (thanks to @alexcrichton for the lock code). This lock only works in Windows and will hold a mutex for the duration of a message output.
r? @nikomatsakis
modify fds-are-cloexec test to open a file that exists
Fixes#35753.
Is it a valid assumption that the current directory is always the root of the repo when the tests are run?
r? @nagisa
We originally imported this into the repository with the intent of
fixing it up. Instead, nothing happened.
Its appearance on rust-lang.org makes it seem semi-official, but it's
not. The rustfmt strike team will end up producing something like this
anyway, and leaving it around does nothing but mislead people.
Deny (by default) transmuting from fn item types to pointer-sized types.
This sets the #19925 lint (transmute from zero-sized fn item type) to `deny` by default.
Technically a `[breaking-change]`, but will not affect dependent crates because of `--cap-lints`.
Use arc4rand(9) on FreeBSD
From rust-lang-nursery/rand#112:
>After reading through #30691 it seems that there's general agreement that using OS-provided facilities for seeding rust userland processes is fine as long as it doesn't use too much from libc. FreeBSD's `arc4random_buf(3)` is not only a whole lot of libc code, but also not even currently exposed in the libc crate. Fortunately, the mechanism `arc4random_buf(3)` et al. use for getting entropy from the kernel ([`arc4rand(9)`](https://www.freebsd.org/cgi/man.cgi?query=arc4random&apropos=0&sektion=9&manpath=FreeBSD+10.3-RELEASE&arch=default&format=html)) is exposed via `sysctl(3)` with constants that are already in the libc crate.
>I haven't found too much documentation on `KERN_ARND`—it's missing or only briefly described in most of the places that cover sysctl mibs. But, from digging through the kernel source, it appears that the sysctl used in this PR is very close to just calling `arc4rand(9)` directly (with `reseed` set to 0 and no way to change it).
I expected [rand](/rust-lang-nursery/rand) to reply quicker, so I tried submitting it there first. It's been a few weeks with no comment, so I don't know the state of it, but maybe someone will see it here and have an opinion. This is basically the same patch. It pains me to duplicate the code but I guess it hasn't been factored out into just one place yet.
rustc_trans: do not generate allocas for unused locals.
This fixes a regression observed in a [`mio` test](https://travis-ci.org/carllerche/mio/jobs/152142886) which was referencing a 4MB `const` array.
Even though MIR rvalue promotion would promote the borrow of the array, a dead temp was left behind.
As the array doesn't have an immediate type, an `alloca` was generated for it, even though it had no uses.
The fix is pretty dumb: assume that locals need to be borrowed or assigned before being used.
And if it can't be used, it doesn't get an `alloca`, even if the type would otherwise demand it.
This could change in the future, but all the MIR we generate now doesn't break that rule.
Fix debug line number info for macro expansions.
Macro expansions result in code tagged with completely different debug locations than the surrounding expressions. This wrecks havoc on debugger's ability the step over source lines.
This change fixes the problem by tagging expanded code as "inlined" at the macro expansion site, which allows the debugger to sort it out.
Note that only the outermost expansion is currently handled, stepping into a macro will still result in stepping craziness.
r? @eddyb
Macro expansions produce code tagged with debug locations that are completely different from the surrounding expressions. This wrecks havoc on debugger's ability the step over source lines.
In order to have a good line stepping behavior in debugger, we overwrite debug locations of macro expansions with that of the outermost expansion site.
rustc: Don't enable NEON by default on armv7 Linux
One of the primary platforms for the `armv7-unknown-linux-gnueabihf` target,
Linux distributions, do not enable NEON extensions by default. This PR disables
that feature by defualt but enables the `d16` feature which enables VFP3D16 that
distributions do enable.
Closes#35590
Remove the old AST-based backend from rustc_trans.
Starting with Rust 1.13, `--disable-orbit` , `-Z orbit=off` and `#[rustc_no_mir]` have been removed.
Only the new MIR backend is left in the compiler, and only early const_eval uses ASTs from other crates.
Filling drop (previously "zeroing drop"), `#[unsafe_no_drop_flag]` and associated unstable APIs are gone.
Implementing `Drop` doesn't add a flag anymore to the type, all of the dynamic drop is function local.
This is a [breaking-change], please use `Option::None` and/or `mem::forget` if you are unsure about your ability to prevent/control the drop of a value. In the future, `union` will be usable in some such cases.
**NOTE**: DO NOT MERGE before we get the new beta as the stage0, there's some cruft to remove.
All of this will massively simplify any efforts to implement (and as such it blocks) features such as `union`s, safe use of `#[packed]` or new type layout optimizations, not to mention many other experiments.
