Rollup of 6 pull requests #42536
Closed
Rollup of 6 pull requests #42536
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This commit removes a few calls to panic and/or assert in `rust_eh_personality`.
This function definitely can't itself panic (that'd probably segfault or do
something else weird) and I was also noticing that a `pub extern fn foo() {}`
cdylib was abnormally large. Turns out all that size was the panicking machinery
brought in by the personality function!
The change here is to return a `Result` internally so we can bubble up the fatal
error, eventually translating to the appropriate error code for the libunwind
ABI.
Should help fix an accidental regression from rust-lang#39386.
Make rustdoc.js use license comments. This will ensure that JS minifiers and the like will preserve the license statement even after minimisation.
Vec<T> is pronounced 'vec' I've never heard it pronounced "vector". Is this an outdated recommendation? (or have I been doing it wrong all this time) r? @steveklabnik
…=vadimcn
std: Avoid panics in rust_eh_personality
This commit removes a few calls to panic and/or assert in `rust_eh_personality`.
This function definitely can't itself panic (that'd probably segfault or do
something else weird) and I was also noticing that a `pub extern fn foo() {}`
cdylib was abnormally large. Turns out all that size was the panicking machinery
brought in by the personality function!
The change here is to return a `Result` internally so we can bubble up the fatal
error, eventually translating to the appropriate error code for the libunwind
ABI.
…hton
bootstrap: improve 'build --help' by explaining what exactly the last example does
I recently found myself confused about what exactly gets built how often when I run which command; I think this would have helped me.
One thing I did not touch, but I feel could also be improved, is the wording just above: "For a quick build with a usable compile, you can pass". I am not a native speaker, but this sounds odd to me. Do you mean "For a quick build of a usable compiler" (but then it should say where the usable compiler is produced)? Or do you mean "For a quick build testing if the compiler is usable"? I can reword this, but I'd like to make sure I understand the intent of the message.
What about
```
For a quick build of a usable compiler, you can pass:
./x.py build --stage 1 src/libtest
This will first build everything once (like --stage 0 without further
arguments would), and then use the compiler built in stage 0 to build
src/libtest and its dependencies.
Once this is done, build/$ARCH/stage1 contains a usable compiler.
```
However, I am not sure this is actually true. In particular, why even bother building the libstd in stage 1? AFAIK that ends up in `build/*/stage1-std`, not in `build/*/stage1` (which is filled from `build/*/stage0-*`).
std: Handle ENOSYS when calling `pipe2` Should help fix an accidental regression from rust-lang#39386.
…=nagisa Ignore variadic FFI test on AArch64 I've cross compiled Rust to `aarch64-linux-gnu`, and tried to run the compile-fail tests, but `variadic-ffi.rs` fails with the following error: ``` The ABI `"stdcall"` is not supported for the current target [E0570] ``` The test seems to be ignored on (32-bit) ARM, so I turned it off for AArch64 too.
|
Some changes occurred in HTML/CSS. |
|
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @nikomatsakis (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
|
@bors r+ p=10 |
|
📌 Commit d80ac82 has been approved by |
|
💔 Test failed - status-travis |
|
The mac build (x86_64-check on Xcode 8.2) timed out after 3 hours.
Compared with the last successful merge,
It looks like the stage1 build time is suddenly doubled. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
pipe2#42521, Ignore variadic FFI test on AArch64 #42531