-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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 #64932
Merged
Merged
Rollup of 9 pull requests #64932
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
rust-lang#49496 introduced specialization based on: ``` unsafe impl<T: ?Sized> IsZero for *mut T { fn is_zero(&self) -> bool { (*self).is_null() } } ``` … to call `RawVec::with_capacity_zeroed` for creating `Vec<*mut T>`, which is incorrect for fat pointers since `<*mut T>::is_null` only looks at the data component. That is, a fat pointer can be “null” without being made entirely of zero bits. This commit fixes it by removing the `?Sized` bound on this impl (and the corresponding `*const T` one). This regresses `vec![x; n]` with `x` a null raw slice of length zero, but that seems exceptionally uncommon. (Vtable pointers are never null, so raw trait objects would not take the fast path anyway. An alternative to keep the `?Sized` bound (or even generalize to `impl<U: Copy> IsZero for U`) would be to cast to `&[u8]` of length `size_of::<U>()`, but the optimizer seems not to be able to propagate alignment information and sticks with comparing one byte at a time: https://rust.godbolt.org/z/xQFkwL ---- Without the library change, the new test fails as follows: ``` ---- vec::vec_macro_repeating_null_raw_fat_pointer stdout ---- [src/liballoc/tests/vec.rs:1301] ptr_metadata(raw_dyn) = 0x00005596ef95f9a8 [src/liballoc/tests/vec.rs:1306] ptr_metadata(vec[0]) = 0x0000000000000000 thread 'vec::vec_macro_repeating_null_raw_fat_pointer' panicked at 'assertion failed: vec[0] == null_raw_dyn', src/liballoc/tests/vec.rs:1307:5 ```
…d `Option<Box<T>>`
Now we can use the dataflow graphviz debugging.
Add long error explanation for E0493 Part of rust-lang#61137.
Use https for curl when building for linux I noticed that the dist-x86_64-linux builder uses http to fetch curl and doesn't do any signature verification. It should probably use https. r? @alexcrichton @Mark-Simulacrum
…phviz, r=oli-obk Graphviz debug output for generic dataflow analysis A follow up to rust-lang#64566. This outputs graphviz diagrams in the generic dataflow engine when `#[rustc_mir(borrowck_graphviz_postflow="suffix.dot")]` is set on an item. This code is based on [`dataflow/graphviz.rs`](https://github.com/rust-lang/rust/blob/master/src/librustc_mir/dataflow/graphviz.rs), but displays different information since there are no "gen"/"kill" sets and transfer functions cannot be coalesced in the generic analysis. As a result, we show the dataflow state at the start and end of each block, as well as the changes resulting from each statement. I also render the state bitset in full (`{_1,_2}`) instead of hex-encoded as the current renderer does (`06`).
…-e0550, r=oli-obk Add long error explanation for E0550 Part of rust-lang#61137
…ackler Fix `vec![x; n]` with null raw fat pointer zeroing the pointer metadata rust-lang#49496 introduced specialization based on: ```rust unsafe impl<T: ?Sized> IsZero for *mut T { fn is_zero(&self) -> bool { (*self).is_null() } } ``` … to call `RawVec::with_capacity_zeroed` for creating `Vec<*mut T>`, which is incorrect for fat pointers since `<*mut T>::is_null` only looks at the data component. That is, a fat pointer can be “null” without being made entirely of zero bits. This commit fixes it by removing the `?Sized` bound on this impl (and the corresponding `*const T` one). This regresses `vec![x; n]` with `x` a null raw slice of length zero, but that seems exceptionally uncommon. (Vtable pointers are never null, so raw trait objects would not take the fast path anyway.) An alternative to keep the `?Sized` bound (or even generalize to `impl<U: Copy> IsZero for U`) would be to cast to `&[u8]` of length `size_of::<U>()`, but the optimizer seems not to be able to propagate alignment information and sticks with comparing one byte at a time: https://rust.godbolt.org/z/xQFkwL ---- Without the library change, the new test fails as follows: ```rust ---- vec::vec_macro_repeating_null_raw_fat_pointer stdout ---- [src/liballoc/tests/vec.rs:1301] ptr_metadata(raw_dyn) = 0x00005596ef95f9a8 [src/liballoc/tests/vec.rs:1306] ptr_metadata(vec[0]) = 0x0000000000000000 thread 'vec::vec_macro_repeating_null_raw_fat_pointer' panicked at 'assertion failed: vec[0] == null_raw_dyn', src/liballoc/tests/vec.rs:1307:5 ```
…ckler Zero-initialize `vec![None; n]` for `Option<&T>`, `Option<&mut T>` and `Option<Box<T>>`
Fixed a misleading documentation issue rust-lang#64844 Made the suggested change from @steveklabnik on issue rust-lang#64844
Add test for issue-64662 Closes rust-lang#64662 r? @varkor
…nas-schievink Add missing links for mem::needs_drop r? @jonas-schievink
@bors r+ p=9 rollup=never |
📌 Commit 913c095 has been approved by |
bors
added
the
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
label
Sep 30, 2019
⌛ Testing commit 913c095 with merge 50e67a00f2c9c85bac9892a0008f73aeb93a84ba... |
💥 Test timed out |
bors
added
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
and removed
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
labels
Oct 1, 2019
@bors retry |
bors
added
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
and removed
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
labels
Oct 1, 2019
bors
added a commit
that referenced
this pull request
Oct 1, 2019
Rollup of 9 pull requests Successful merges: - #64377 (Add long error explanation for E0493) - #64786 (Use https for curl when building for linux) - #64828 (Graphviz debug output for generic dataflow analysis) - #64838 (Add long error explanation for E0550) - #64891 (Fix `vec![x; n]` with null raw fat pointer zeroing the pointer metadata) - #64893 (Zero-initialize `vec![None; n]` for `Option<&T>`, `Option<&mut T>` and `Option<Box<T>>`) - #64911 (Fixed a misleading documentation issue #64844) - #64921 (Add test for issue-64662) - #64923 (Add missing links for mem::needs_drop) Failed merges: - #64918 (Add long error explanation for E0551) r? @ghost
☀️ Test successful - checks-azure |
tmandry
added
the
A-spurious
Area: Spurious failures in builds (spuriously == for no apparent reason)
label
Oct 1, 2019
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
A-spurious
Area: Spurious failures in builds (spuriously == for no apparent reason)
merged-by-bors
This PR was explicitly merged by bors.
rollup
A PR which is a rollup
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
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:
vec![x; n]
with null raw fat pointer zeroing the pointer metadata #64891 (Fixvec![x; n]
with null raw fat pointer zeroing the pointer metadata)vec![None; n]
forOption<&T>
,Option<&mut T>
andOption<Box<T>>
#64893 (Zero-initializevec![None; n]
forOption<&T>
,Option<&mut T>
andOption<Box<T>>
)std::option
module #64844)Failed merges:
r? @ghost