Rollup of 7 pull requests #52229
Merged
Rollup of 7 pull requests #52229
Conversation
This file contains hidden or 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
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 issue was reported to security@rust-lang.org by Sebastien Marie following our recent [security advisory][1]. Because `/tmp` is typically globally writable it's possible for one user to place symlinks in `/tmp` pointing to files in another user's directories, causing `rustc` to overwrite the contents of innocent files by accident. This patch instead defaults the output path here to the cwd which should avoid this issue. [1]: https://blog.rust-lang.org/2018/07/06/security-advisory-for-rustdoc.html
…r=pnkfelix NLL: fix E0594 "change to mutable ref" suggestion Fix rust-lang#51515. Fix rust-lang#51879. Questions: - [x] Is this the right place to fix this? It feels brittle, being so close to the frontend. **It's probably fine.** - [ ] Have I missed any other cases that trigger this behavior? - [x] Is it okay to use HELP and SUGGESTION in the UI test? **Yes.** - [x] Do I need more tests for this? **No.**
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).
… r=QuietMisdreavus Trait impl settings Fixes rust-lang#51797. r? @QuietMisdreavus PS: I was annoyed by some intra link failures so I fixed them as well.
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`).
rustc: Avoid /tmp/ in graphviz writing This issue was reported to security@rust-lang.org by Sebastien Marie following our recent [security advisory][1]. Because `/tmp` is typically globally writable it's possible for one user to place symlinks in `/tmp` pointing to files in another user's directories, causing `rustc` to overwrite the contents of innocent files by accident. This patch instead defaults the output path here to the cwd which should avoid this issue. [1]: https://blog.rust-lang.org/2018/07/06/security-advisory-for-rustdoc.html
|
@bors: r+ p=7 |
|
📌 Commit d5c9078 has been approved by |
bors
added
the
S-waiting-on-bors
bors
added a commit
that referenced
this pull request
Jul 10, 2018
Rollup of 7 pull requests Successful merges: - #51612 (NLL: fix E0594 "change to mutable ref" suggestion) - #51722 (Updated RELEASES for 1.28.0) - #52064 (Clarifying how the alignment of the struct works) - #52149 (Add #[repr(transparent)] to Atomic* types) - #52151 (Trait impl settings) - #52171 (Correct some codegen stats counter inconsistencies) - #52195 (rustc: Avoid /tmp/ in graphviz writing) Failed merges: - #52164 (use proper footnote syntax for references) r? @ghost
|
☀️ Test successful - status-appveyor, status-travis |
# for free
to join this conversation on GitHub.
Already have an account?
# 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.
Successful merges:
Failed merges:
r? @ghost