Skip to content
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 25 commits into from
Oct 1, 2019
Merged

Rollup of 9 pull requests #64932

merged 25 commits into from
Oct 1, 2019

Conversation

tmandry
Copy link
Member

@tmandry tmandry commented Sep 30, 2019

Successful merges:

Failed merges:

r? @ghost

SimonSapin and others added 25 commits September 29, 2019 11:06
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
```
Now we can use the dataflow graphviz debugging.
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
…nas-schievink

Add missing links for mem::needs_drop

r? @jonas-schievink
@tmandry
Copy link
Member Author

tmandry commented Sep 30, 2019

@bors r+ p=9 rollup=never

@bors
Copy link
Contributor

bors commented Sep 30, 2019

📌 Commit 913c095 has been approved by tmandry

@bors 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
@bors
Copy link
Contributor

bors commented Sep 30, 2019

⌛ Testing commit 913c095 with merge 50e67a00f2c9c85bac9892a0008f73aeb93a84ba...

@bors
Copy link
Contributor

bors commented Oct 1, 2019

💥 Test timed out

@bors 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
@Centril
Copy link
Contributor

Centril commented Oct 1, 2019

@bors retry

@bors 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
Copy link
Contributor

bors commented Oct 1, 2019

⌛ Testing commit 913c095 with merge 42ec683...

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
@bors
Copy link
Contributor

bors commented Oct 1, 2019

☀️ Test successful - checks-azure
Approved by: tmandry
Pushing 42ec683 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Oct 1, 2019
@bors bors merged commit 913c095 into rust-lang:master Oct 1, 2019
@tmandry tmandry added the A-spurious Area: Spurious failures in builds (spuriously == for no apparent reason) label Oct 1, 2019
@tmandry tmandry deleted the rollup-7t8x1nz branch October 1, 2019 19:00
@Centril Centril added the rollup A PR which is a rollup label Oct 2, 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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants