-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rollup of 9 pull requests #49684
Rollup of 9 pull requests #49684
Conversation
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.
@bors r+ p=9 |
📌 Commit 30c830f has been approved by |
⌛ Testing commit 30c830f050e9e84e9cf2c0a4e6fa71f522deb40a with merge 72a46c7af7b9053c4512ef9aa0ed76cfd12516f1... |
💔 Test failed - status-travis |
Your PR failed on Travis. Through arcane magic we have determined that the following fragments from the build log may contain information about the problem. Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
1 similar comment
Your PR failed on Travis. Through arcane magic we have determined that the following fragments from the build log may contain information about the problem. Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
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.
📌 Commit f4511e2 has been approved by |
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:
☀️ Test successful - status-appveyor, status-travis |
Successful merges:
Failed merges: