-
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 8 pull requests #52199
Rollup of 8 pull requests #52199
Conversation
The docs were not specifying how to compute the alignment of the struct, so I had to spend some time trying to figure out how that works. Found the answer [on this page](http://camlorn.net/posts/April%202017/rust-struct-field-reordering.html): > The total size of this struct is 5, but the most-aligned field is b with alignment 2, so we round up to 6 and give the struct an alignment of 2 bytes.
This allows them to be used in #[repr(C)] structs without warnings. Since rust-lang/rfcs#1649 and rust-lang#35603 they are already documented to have "the same in-memory representation as" their corresponding primitive types. This just makes that explicit.
This is needed for rust-lang/libc#1034.
The previous syntax was causing rustdoc to interpret them as links.
Updated RELEASES for 1.28.0 [Rendered](https://github.com/Aaronepower/rust/blob/master/RELEASES.md) r? @Mark-Simulacrum cc @rust-lang/release
Clarifying how the alignment of the struct works The docs were not specifying how to compute the alignment of the struct, so I had to spend some time trying to figure out how that works. Found the answer [on this page](http://camlorn.net/posts/April%202017/rust-struct-field-reordering.html): > The total size of this struct is 5, but the most-aligned field is b with alignment 2, so we round up to 6 and give the struct an alignment of 2 bytes.
Add #[repr(transparent)] to Atomic* types This allows them to be used in `#[repr(C)]` structs without warnings. Since rust-lang/rfcs#1649 and rust-lang#35603 they are already documented to have "the same in-memory representation as" their corresponding primitive types. This just makes that explicit. This was briefly part of rust-lang#51395, but was controversial and therefore dropped. But it turns out that it's essentially already documented (which I had forgotten).
Copy libgcc as well after building musl This is needed for rust-lang/libc#1034. r? @alexcrichton
use proper footnote syntax for references The previous syntax was causing rustdoc to interpret them as links.
…ebank find and highlight the `&` or `'_` in `region_name` Before: ``` --> $DIR/dyn-trait-underscore.rs:18:5 | LL | fn a<T>(items: &[T]) -> Box<dyn Iterator<Item=&T>> { - | ----- lifetime `'1` appears in this argument LL | Box::new(items.iter()) //~ ERROR cannot infer an appropriate lifetime | ^^^^^^^^^^^^^^^^^^^^^^ cast requires that `'1` must outlive `'static` ``` After: ``` --> $DIR/dyn-trait-underscore.rs:18:5 | LL | fn a<T>(items: &[T]) -> Box<dyn Iterator<Item=&T>> { + | - let's call the lifetime of this reference `'1` LL | Box::new(items.iter()) //~ ERROR cannot infer an appropriate lifetime | ^^^^^^^^^^^^^^^^^^^^^^ cast requires that `'1` must outlive `'static` ``` Not intended as the final end point necessarily in any sense. I intentionally left some to-do points to fill in later: - Does not apply to upvars in closures yet (should be relatively easy) - Does not handle the case where we can't find a precise match very well - And of course we can still tweak wording but shows the basic idea of how to make the `Ty` and `hir::Ty` to find a good spot to highlight. r? @estebank cc @davidtwco
Correct some codegen stats counter inconsistencies I noticed some possible typos/inconsistencies in the codegen counters. For example, `fsub` was getting counted as an integer `sub`, whereas `fadd` was counted as an add. And `addincoming` was only being counted on the initial call. https://github.com/rust-lang/rust/blob/dbd10f81758381339f98994b8d31814cf5e98707/src/librustc_codegen_llvm/builder.rs#L831-L841 Only remaining inconsistencies I can see are things like `fadd_fast` are counted as `fadd`. But the vector versions like `vector_reduce_fmax_fast` are counted as `vector.reduce.fmax_fast` not as their 'base' versions (`vector_reduce_fmax` is counted as `vector.reduce.fmax`).
…hton Warn windows-gnu users that the bundled gcc can't compile Add a `DO NOT USE THIS gcc.exe FOR COMPILATION.txt` file to `lib\rustlib\*-pc-windows-gnu\bin` folders in `windows-gnu` installations in order to warn against attempting to use the bundled `gcc.exe` as a C compiler. I'm pretty sure that location is usually found manually, so this should be easily noticeable. This mistake has been made plenty of times and has lead to misunderstandings: Rust: [Bundled gcc (windows x64) is unable to build any c file](rust-lang#24418) gtk-rs: [Compiling on windows](gtk-rs/gtk#625) bzip2-rs: [Build failure at gcc level: blocksort.c not found](alexcrichton/bzip2-rs#30) Alternatives: rename the bundled `gcc.exe` to e.g. `rustc-gcc.exe` or `gcc-linker.exe`. This might require a more comprehensive change or break crates already using it as a linker. r? @alexcrichton
@bors r+ p=4 |
📌 Commit bb9f494 has been approved by |
⌛ Testing commit bb9f494 with merge dd59301c62820031839dcc530c5f0e5851c30a11... |
💔 Test failed - status-travis |
The job 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
The job 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 |
(Legit, caused by #52157) |
Successful merges:
&
or'_
inregion_name
#52168 (find and highlight the&
or'_
inregion_name
)Failed merges:
r? @ghost