resolving it as a dependency.

Fixes rust-lang#46816

A problem caused by not doing so in Chrome has been reported here:
https://randomascii.wordpress.com/2018/02/25/compiler-bug-linker-bug-windows-kernel-bug/amp/

File::sync_all() calls FlushFileBuffers() down the line,
causing potentially unflushed buffers on high I/O-load systems to flush
and prevent nasty non-reproducible bugs.

The force-flush is only done on Windows and if the linker exited successfully

Closes rust-lang#48545

This adds a new method to all numeric `Atomic*` types with a
safe compare-and-set loop, so users will no longer need to write
their own, except in *very* strange circumstances.

This solves rust-lang#48384 with `x.fetch_max(_)`/`x.fetch_min(_)`. It
also relates to rust-lang#48655 (which I misuse as tracking issue for now).

*note* This *might* need a crater run because the functions could
clash with third party extension traits.

This should be enough and shouldn't require append(true) since we're not
explicitly writing anything so we're not flushing it so we've no risk of
overwriting it

the rust-std component only contains the core and compiler-builtins (+c +mem) crates

cc rust-lang#49382

vec![0; n], via implementations of SpecFromElem, has an optimization
that uses with_capacity_zeroed instead of with_capacity, which will use
calloc instead of malloc, and avoid an extra memset.

This adds the same optimization for vec![ptr::null(); n] and
vec![ptr::null_mut(); n], assuming their bit value is 0 (which is true
on all currently supported platforms).

This does so by adding an intermediate trait IsZero, which looks very
much like nonzero::Zeroable, but that one is on the way out, and doesn't
apply to pointers anyways.

Adding such a trait allows to avoid repeating the logic using
with_capacity_zeroed or with_capacity, or making the macro more complex
to support generics.

Similarly to vec![ptr::null{,_mut}(); n] in previous change, this adds
the optimization for vec!['\0'; n].

the goal is to build, in a single Cargo invocation, several no-std crates that we want to put in the
rust-std component of no-std targets. The nostd crate builds these crates:

- core
- compiler-builtin (with the "c" and "mem" features enabled)
- alloc
- std_unicode

This reverts commit 14768f9.

This builder is starting to time out frequently causing PRs to bounce and
otherwise doesn't seem to be catching too many bugs, so this commit removes it
entirely. We've had a number of timeouts in the last few weeks related to this
builder:

* https://travis-ci.org/rust-lang/rust/jobs/360947582
* https://travis-ci.org/rust-lang/rust/jobs/360464190
* https://travis-ci.org/rust-lang/rust/jobs/359946975
* https://travis-ci.org/rust-lang/rust/jobs/361213241
* https://travis-ci.org/rust-lang/rust/jobs/362346279
* https://travis-ci.org/rust-lang/rust/jobs/362072331

On a good run this builder takes about 2h15m, which is already too long for
Travis and the variable build times end up pushing it beyond the 3h limit
occasionally.

The timeouts here are somewhat expected in that an incrementally compiled rustc
compiler isn't optimized like a normal rustc, disallowing inlining between
codegen units and losing lots of optimization opportunities.

Add a generic CAS loop to std::sync::Atomic*

This adds two new methods to both `AtomicIsize` and `AtomicUsize` with optimized safe compare-and-set loops, so users will no longer need to write their own, except in *very* strange circumstances.

`update_and_fetch` will apply the function and return its result, whereas `fetch_and_update` will apply the function and return the previous value.

This solves rust-lang#48384 with `x.update_and_fetch(|x| x.max(y))`. It also relates to rust-lang#48655 (which I misuse as tracking issue for now)..

*note* This *might* need a crater run because the functions could clash with third party extension traits.

…chton

Take the original extra-filename passed to a crate into account when resolving it as a dependency

resolving it as a dependency.

Fixes rust-lang#46816

RFC 2008: Finishing Touches

Part of rust-lang#44109.

r? @nikomatsakis
(not sure who was best for this PR).

…rister

Flush executables to disk after linkage

A problem caused by not doing so in Chrome has been reported [here](https://randomascii.wordpress.com/2018/02/25/compiler-bug-linker-bug-windows-kernel-bug/amp/).

`File::sync_all()` calls `FlushFileBuffers()` down the line, causing potentially unflushed buffers on high I/O-load systems to flush and preventing nasty non-reproducible bugs.

Closes rust-lang#48545

Add more vec![... ; n] optimizations

vec![0; n], via implementations of SpecFromElem, has an optimization that uses with_capacity_zeroed instead of with_capacity, which will use calloc instead of malloc, and avoid an extra memset.

This PR adds the same optimization for ptr::null, ptr::null_mut, and None, when their in-memory representation is zeroes.

add a dist builder to build rust-std components for the THUMB targets

the rust-std component only contains the core and compiler-builtins (+c +mem) crates

cc rust-lang#49382

- I'm not entirely sure if this PR alone will produce rust-std components installable by rustup or if something else needs to be changed
- I could have done the THUMB builds in an existing builder / image; I wasn't sure if that was a good idea so I added a new image
- I could build other crates like alloc into the rust-std component but, AFAICT, that would require calling Cargo a second time (one for alloc and one for compiler-builtins), or have alloc depend on compiler-builtins (rust-lang#49503 will perform that change) *and* have alloc resurface the "c" and "mem" Cargo features.

r? @alexcrichton

Host compiler documentation: Include private items

Fixes rust-lang#29893. Now that compiler documentation is being hosted, including private items seems sensible as these types are going to be being used by contributors working on the compiler.

However, including this means that doc comments that contain codeblocks with invalid Rust and can fail the documenting of a given crate (as evidenced by the changes in the second commit included in this PR). We'd need some way of ensuring that this cannot happen so that these failures don't cause documenting to fail. I'm unsure whether this change to documentation steps will cause this to happen already or if something new will be required.

r? @alexcrichton

…omatsakis

Add more features to rust_2018_preview

Doesn't handle lib features like never_type; we need to figure out a scheme for that.

…r=michaelwoerister

ci: Remove x86_64-gnu-incremental builder

This builder is starting to time out frequently causing PRs to bounce and
otherwise doesn't seem to be catching too many bugs, so this commit removes it
entirely. We've had a number of timeouts in the last few weeks related to this
builder:

* https://travis-ci.org/rust-lang/rust/jobs/360947582
* https://travis-ci.org/rust-lang/rust/jobs/360464190
* https://travis-ci.org/rust-lang/rust/jobs/359946975
* https://travis-ci.org/rust-lang/rust/jobs/361213241
* https://travis-ci.org/rust-lang/rust/jobs/362346279
* https://travis-ci.org/rust-lang/rust/jobs/362072331

On a good run this builder takes about 2h15m, which is already too long for
Travis and the variable build times end up pushing it beyond the 3h limit
occasionally.

The timeouts here are somewhat expected in that an incrementally compiled rustc
compiler isn't optimized like a normal rustc, disallowing inlining between
codegen units and losing lots of optimization opportunities.