A small amount of tidying-up factored out from PR #64648
As requested by @Mark-Simulacrum, I put this in a separate commit to make it easier to review. (As far as I can tell, no violations of the policy here, and they are simply in a separate PR because they're not directly related to the import of that PR.)
r? @Mark-Simulacrum
Remove legacy grammar
Revival of #50835 & #55545
On the #wg-grammar discord there was agreement that enough progress has been made to be able to remove the legacy grammar.
r? @Centril @qmx
cc @rust-lang/wg-grammar
async/await: improve not-send errors
cc #64130.
```
note: future does not implement `std::marker::Send` because this value is used across an await
--> $DIR/issue-64130-non-send-future-diags.rs:15:5
|
LL | let g = x.lock().unwrap();
| - has type `std::sync::MutexGuard<'_, u32>`
LL | baz().await;
| ^^^^^^^^^^^ await occurs here, with `g` maybe used later
LL | }
| - `g` is later dropped here
```
r? @nikomatsakis
syntax: recover trailing `|` in or-patterns
Fixes https://github.com/rust-lang/rust/issues/64879.
For example (this also shows that we are sensitive to the typo `||`):
```
error: a trailing `|` is not allowed in an or-pattern
--> $DIR/remove-leading-vert.rs:33:11
|
LL | A || => {}
| - ^^ help: remove the `||`
| |
| while parsing this or-pattern starting here
|
= note: alternatives in or-patterns are separated with `|`, not `||`
```
r? @estebank
syntax: Support modern attribute syntax in the `meta` matcher
Where "modern" means https://github.com/rust-lang/rust/pull/57367:
```
PATH
PATH `(` TOKEN_STREAM `)`
PATH `[` TOKEN_STREAM `]`
PATH `{` TOKEN_STREAM `}`
```
Unfortunately, `meta` wasn't future-proofed using the `FOLLOW` token set like other matchers (https://github.com/rust-lang/rust/issues/34011), so code like `$meta:meta {` or `$meta:meta [` may break, and we need a crater run to find out how often this happens in practice.
Closes https://github.com/rust-lang/rust/issues/49629 (by fully supporting `meta` rather than removing it.)
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
This commit improves obligation errors for async/await:
```
note: future does not implement `std::marker::Send` because this value is used across an
await
--> $DIR/issue-64130-non-send-future-diags.rs:15:5
|
LL | let g = x.lock().unwrap();
| - has type `std::sync::MutexGuard<'_, u32>`
LL | baz().await;
| ^^^^^^^^^^^ await occurs here, with `g` maybe used later
LL | }
| - `g` is later dropped here
```
Signed-off-by: David Wood <david@davidtw.co>
Fix `vec![x; n]` with null raw fat pointer zeroing the pointer metadata
https://github.com/rust-lang/rust/pull/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
```
Graphviz debug output for generic dataflow analysis
A follow up to #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`).
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
Remove manual unrolling from slice::Iter(Mut)::try_fold
While this definitely helps sometimes (particularly for trivial closures), it's also a pessimization sometimes, so it's better to leave this to (hypothetical) future LLVM improvements instead of forcing this on everyone.
I think it's better for the advice to be that sometimes you need to unroll manually than you sometimes need to not-unroll manually (like #64545).
---
For context see https://github.com/rust-lang/rust/pull/64572#issuecomment-532961046
rustdoc: Fix default logo filename
This was a typo made in #64443. It's the reason the logo is missing on the [nightly docs](https://doc.rust-lang.org/nightly/std/).
r? @Mark-Simulacrum
Optimize try_eval_bits to avoid layout queries
This specifically targets match checking, but is possibly more widely
useful as well. In code with large, single-value match statements, we
were previously spending a lot of time running layout_of for the
primitive types (integers, chars) -- which is essentially useless. This
optimizes the code to avoid those query calls by directly obtaining the
size for these types, when possible.
It may be worth considering adding a `size_of` query in the future which
might be far faster, especially if specialized for "const" cases --
match arms being the most obvious example. It's possibly such a function
would benefit from *not* being a query as well, since it's trivially
evaluatable from the sty for many cases whereas a query needs to hash
the input and such.
This specifically targets match checking, but is possibly more widely
useful as well. In code with large, single-value match statements, we
were previously spending a lot of time running layout_of for the
primitive types (integers, chars) -- which is essentially useless. This
optimizes the code to avoid those query calls by directly obtaining the
size for these types, when possible.
It may be worth considering adding a `size_of` query in the future which
might be far faster, especially if specialized for "const" cases --
match arms being the most obvious example. It's possibly such a function
would benefit from *not* being a query as well, since it's trivially
evaluatable from the sty for many cases whereas a query needs to hash
the input and such.
