-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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 11 pull requests #49675
Rollup of 11 pull requests #49675
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 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].
This commit applies a few code size optimizations for the wasm target to the standard library, namely around panics. We notably know that in most configurations it's impossible for us to print anything in wasm32-unknown-unknown so we can skip larger portions of panicking that are otherwise simply informative. This allows us to get quite a nice size reduction. Finally we can also tweak where the allocation happens for the `Box<Any>` that we panic with. By only allocating once unwinding starts we can reduce the size of a panicking wasm module from 44k to 350 bytes.
So we can cut some params by using stuff from the environment.
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.
💔 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 |
…gs, r=nikomatsakis Small typeck refactorings Some code improvements I noticed while reading the code.
…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
…ackler std: Minimize size of panicking on wasm This commit applies a few code size optimizations for the wasm target to the standard library, namely around panics. We notably know that in most configurations it's impossible for us to print anything in wasm32-unknown-unknown so we can skip larger portions of panicking that are otherwise simply informative. This allows us to get quite a nice size reduction. Finally we can also tweak where the allocation happens for the `Box<Any>` that we panic with. By only allocating once unwinding starts we can reduce the size of a panicking wasm module from 44k to 350 bytes.
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
Rerunning tests in single-threaded mode yields:
Likely candidate appears to be #49392, so removing that and retrying. |
@bors: r+ |
📌 Commit f8e3584 has been approved by |
⌛ Testing commit f8e3584 with merge 94e5c173fe8c78c83695a8dad81267dfaa1599a2... |
@bors: r- hm local testing shows this is still failing |
@bors: retry |
Alas, after testing a few PRs I cannot find the culprit... |
Successful merges:
Failed merges:
extern {}
blocks #49350 (Expand macros inextern {}
blocks)