Rollup of 9 pull requests
Successful merges:
- #48658 (Add a generic CAS loop to std::sync::Atomic*)
- #49253 (Take the original extra-filename passed to a crate into account when resolving it as a dependency)
- #49345 (RFC 2008: Finishing Touches)
- #49432 (Flush executables to disk after linkage)
- #49496 (Add more vec![... ; n] optimizations)
- #49563 (add a dist builder to build rust-std components for the THUMB targets)
- #49654 (Host compiler documentation: Include private items)
- #49667 (Add more features to rust_2018_preview)
- #49674 (ci: Remove x86_64-gnu-incremental builder)
Failed merges:
Host compiler documentation: Include private items
Fixes#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
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 #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 (#49503 will perform that change) *and* have alloc resurface the "c" and "mem" Cargo features.
r? @alexcrichton
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.
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#48545
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 #48384 with `x.update_and_fetch(|x| x.max(y))`. It also relates to #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.
Rollup of 25 pull requests
Successful merges:
- #49179 (Handle future deprecation annotations )
- #49512 (Add support for variant and types fields for intra links)
- #49515 (fix targetted value background)
- #49516 (Add missing anchor for union type fields)
- #49532 (Add test for rustdoc ignore test)
- #49533 (Add #[must_use] to a few standard library methods)
- #49540 (Fix miri Discriminant() for non-ADT)
- #49559 (Introduce Vec::resize_with method (see #41758))
- #49570 (avoid IdxSets containing garbage above the universe length)
- #49577 (Stabilize String::replace_range)
- #49599 (Fix typo)
- #49603 (Fix url for intra link provided method)
- #49607 (Stabilize iterator methods in 1.27)
- #49609 (run-pass/attr-stmt-expr: expand test cases)
- #49612 (Fix "since" version for getpid feature.)
- #49618 (Fix build error when compiling libcore for 16bit targets)
- #49619 (tweak core::fmt docs)
- #49637 (Stabilize parent_id())
- #49639 (Update Cargo)
- #49628 (Re-write the documentation index)
- #49594 (Add some performance guidance to std::fs and std::io docs)
- #49625 (miri: add public alloc_kind accessor)
- #49634 (Add a test for the fix to issue #43058)
- #49641 (Regression test for #46314)
- #49547 (Unignore borrowck test)
Failed merges:
Add some performance guidance to std::fs and std::io docs
Adds more documentation about performance to various "read" functions in `fs` and `io`, and to `BufReader`/`BufWriter`, with the goal of helping developers choose the best option for a given task.
Re-write the documentation index
The docs team has decided that we're framing resources in three ways:
"learning Rust," "using Rust," "mastering Rust." This is a more useful
split than "beginner/intermediate/advanced." As we add more resources
in the future, we expect "using Rust" to grow. "the bookshelf" as a
concept is great, but isn't really organized along these lines. As such,
this reorganizes the docs along these lines.
Better document the implementors of Clone and Copy
There are two parts to this change. The first part is a change to the compiler and to the standard library (specifically, libcore) to allow implementations of `Clone` and `Copy` to be written for a subset of builtin types. By adding these implementations to libcore, they now show up in the documentation. This is a [breaking-change] for users of `#![no_core]`, because they will now have to supply their own copy of the implementations of `Clone` and `Copy` that were added in libcore.
The second part is purely a documentation change to document the other implementors of `Clone` and `Copy` that cannot be described in Rust code (yet) and are thus provided by the compiler.
Fixes#25893
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
Add tests to rustbuild
In order to run tests, we cfg out various parts of rustbuild. Generally
speaking, these are filesystem and process-spawning operations. Then, rustbuild
is run "as normal" and the various steps that where run are retrieved from the
cache and checked against the expected results.
Note that this means that the current implementation primarily tests "what" we
build, but doesn't actually test that what we build *will* build. In other
words, it doesn't do any form of dependency verification for any crate. This is
possible to implement, but is considered future work.
This implementation strives to cfg out as little code as possible; it also does
not currently test anywhere near all of rustbuild. The current tests are also
not checked for "correctness," rather, they simply represent what we do as of
this commit, which may be wrong.
Test cases are drawn from the old implementation of rustbuild, though the
expected results may vary.
r? @alexcrichton
avoid IdxSets containing garbage above the universe length
This makes sure that all bits in each IdxSet between the universe length
and the end of the word are all zero instead of being in an indeterminate state.
This fixes a crash with RUST_LOG=rustc_mir, and is probably a good idea
anyway.
r? @nikomatsakis - I think you are responsible for this code area now?
Introduce Vec::resize_with method (see #41758)
In #41758, the libs team decided they preferred `Vec::resize_with` over `Vec::resize_default()`. Here is an implementation to get this moving forward.
I don't know what the removal process for `Vec::resize_default()` should be, so I've left it in place for now. Would be happy to follow up with its removal.
Add #[must_use] to a few standard library methods
Chosen to start a precedent of using it on ones that are potentially-expensive and where using it for side effects is particularly discouraged.
Discuss :)
```rust
warning: unused return value of `std::iter::Iterator::collect` which must be used: if you really need to exhaust the iterator, consider `.for_each(drop)` instead
--> $DIR/fn_must_use_stdlib.rs:19:5
|
LL | "1 2 3".split_whitespace().collect::<Vec<_>>();
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
warning: unused return value of `std::borrow::ToOwned::to_owned` which must be used: cloning is often expensive and is not expected to have side effects
--> $DIR/fn_must_use_stdlib.rs:21:5
|
LL | "hello".to_owned();
| ^^^^^^^^^^^^^^^^^^^
warning: unused return value of `std::clone::Clone::clone` which must be used: cloning is often expensive and is not expected to have side effects
--> $DIR/fn_must_use_stdlib.rs:23:5
|
LL | String::from("world").clone();
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
```
cc https://github.com/rust-lang/rust/issues/48926
