Silence unreachable code lint from await desugaring
Fixes#61798.
This PR silences the unreachable code lint when it originates from within an await desugaring.
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
Closure typing obligations flow in both direcitons to properly infer
types. Because of this, we will get 2 type errors whenever there's
an unfulfilled obligation. To avoid this, we deduplicate them in the
`InferCtxt`.
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
This changes the default parallelism for parallel compilers to one,
instead of the previous default, which was "num cpus". This is likely
not an optimal default long-term, but it is a good default for testing
whether parallel compilers are not a significant regression over a
sequential compiler.
Notably, this in theory makes a parallel-enabled compiler behave
exactly like a sequential compiler with respect to the jobserver.
