This is useful for debugging drop-tracking; previously, you had to recompile
rustc from source and manually add a call to `write_graph_to_file`. This
makes the option more discoverable and configurable at runtime.

I also took the liberty of making the labels for the CFG nodes much easier to read:
previously, they looked like `id(2), local_id: 48`, now they look like
```
expr from_config (hir_id=HirId { owner: DefId(0:10 ~ default_struct_update[79f9]::foo), local_id: 2})
```

Some of these are a little questionable because the output is so much longer, but I would really love to keep the bit that adds the pretty-printed expression to the generated CFG .dot file.

Before:
```
DEBUG rustc_typeck::check::generator_interior::drop_ranges::record_consumed_borrow consume PlaceWithHirId { hir_id: HirId { owner: DefId(0:7 ~ default_struct_update[79f9]::foo), local_id: 15 }, place: Place { base_ty: impl std::future::Future<Output = ()>, base: Rvalue, projections: [] } }; diag_expr_id=HirId { owner: DefId(0:7 ~ default_struct_update[79f9]::foo), local_id: 15 }, using parent expr HirId { owner: DefId(0:7 ~ default_struct_update[79f9]::foo), local_id: 49 }
```

After:
```
DEBUG rustc_typeck::check::generator_interior::drop_ranges::record_consumed_borrow consume PlaceWithHirId { hir_id: HirId { owner: DefId(0:7 ~ default_struct_update[79f9]::foo), local_id: 15 }, place: Place { base_ty: impl std::future::Future<Output = ()>, base: Rvalue, projections: [] } }; diag_expr_id=expr from_config(Config {
        nickname: None,
        ..Default::default()
    }) (hir_id=HirId { owner: DefId(0:7 ~ default_struct_update[79f9]::foo), local_id: 15 }), using parent expr
    .await (hir_id=HirId { owner: DefId(0:7 ~ default_struct_update[79f9]::foo), local_id: 49 })
```

When moving this to rustbuild, I introduced a bug: if you had the file already downloaded, but
deleted the sysroot for whatever reason, rustbuil would fail to unpack the cached tarball.

This only affects people if they have a cached tarball, which is probably why we haven't seen an issue yet -
wiping `build/cache` would work around the issue, or just not deleting `build/$TARGET/stage2`.

Formerly `-Zterminal-width`, `--terminal-width` allows the user or build
tool to inform rustc of the width of the terminal so that diagnostics
can be truncated.

Signed-off-by: David Wood <[email protected]>

Rename the `--terminal-width` flag to `--output-width` as the behaviour
doesn't just apply to terminals (and so is slightly less accurate).

Signed-off-by: David Wood <[email protected]>

Rename the `--output-width` flag to `--diagnostic-width` as this appears
to be the preferred name within the compiler team.

Signed-off-by: David Wood <[email protected]>

There are several indications that we should not ZST as a ScalarInt:
- We had two ways to have ZST valtrees, either an empty `Branch` or a `Leaf` with a ZST in it.
  `ValTree::zst()` used the former, but the latter could possibly arise as well.
- Likewise, the interpreter had `Immediate::Uninit` and `Immediate::Scalar(Scalar::ZST)`.
- LLVM codegen already had to special-case ZST ScalarInt.

So instead add new ZST variants to those types that did not have other variants
which could be used for this purpose.

Related to rust-lang#99021.

This lint seems to have been broken by rust-lang#98446

…esolve_region, and remove RootEmptyRegion

…ion, r=oli-obk

sess: stabilize `--terminal-width` as `--diagnostic-width`

Formerly `-Zterminal-width`, `--terminal-width` allows the user or build
tool to inform rustc of the width of the terminal so that diagnostics
can be truncated.

Pending agreement to stabilize, see tracking issue at rust-lang#84673.

r? `@oli-obk`

…holk

Add a `-Zdump-drop-tracking-cfg` debugging flag

This is useful for debugging drop-tracking; previously, you had to recompile
rustc from source and manually add a call to `write_graph_to_file`. This
makes the option more discoverable and configurable at runtime.

I also took the liberty of making the labels for the CFG nodes much easier to read:
previously, they looked like `id(2), local_id: 48`, now they look like
```
expr from_config (hir_id=HirId { owner: DefId(0:10 ~ default_struct_update[79f9]::foo), local_id: 2})
```

r? `@eholk`

…stebank

Fix last `let_chains` blocker

In order to forbid things like `let x = (let y = 1);` or `if let a = 1 && { let x = let y = 1; } {}`, the parser **HAS** to know the context of `let`.

This context thing is not a surprise in the parser because you can see **a lot** of ad hoc fixes mixing parsing logic with validation logic creating code that looks more like spaghetti with tomato sauce.

To make things even greater, a new ad hoc fix was added to only allow `let`s in a valid `let_chains` context by checking the previously processed token. This was the only solution I could think of and believe me, I thought about it for a long time 👍

In the long term, it should be preferable to segregate different responsibilities or create a more robust and cleaner parser framework.

cc rust-lang#94927
cc rust-lang#53667

…anup, r=compiler-errors

A few cleanups

Each commit is (mostly) self-explanatory. These changes have come as I try to remove `ReEmpty` (rust-lang#98559).

…k-Simulacrum

Fix caching bug in `download-rustc = true`

When moving this to rustbuild, I introduced a bug: if you had the file already downloaded, but
deleted the sysroot for whatever reason, rustbuil would fail to unpack the cached tarball.

This only affects people if they have a cached tarball, which is probably why we haven't seen an issue yet -
wiping `build/cache` would work around the issue, or just not deleting `build/$TARGET/stage2`.

Fixes the following error:
```
thread 'main' panicked at 'fs::read_dir(&lib_dir) failed with No such file or directory (os error 2) ("/home/jnelson/rust-lang/rust2/build/x86_64-unknown-linux-gnu/ci-rustc/lib")', config.rs:1563:20
```

r? `@Mark-Simulacrum`

…oli-obk

 don't allow ZST in ScalarInt

There are several indications that we should not ZST as a ScalarInt:
- We had two ways to have ZST valtrees, either an empty `Branch` or a `Leaf` with a ZST in it.
  `ValTree::zst()` used the former, but the latter could possibly arise as well.
- Likewise, the interpreter had `Immediate::Uninit` and `Immediate::Scalar(Scalar::ZST)`.
- LLVM codegen already had to special-case ZST ScalarInt.

So I propose we stop using ScalarInt to represent ZST (which are clearly not integers). Instead, we can add new ZST variants to those types that did not have other variants which could be used for this purpose.

Based on rust-lang#98831. Only the commits starting from "don't allow ZST in ScalarInt" are new.

r? `@oli-obk`

Add doc comments in `rustc_middle::mir`

…, r=pierwill

MIR dataflow: Rename function to `always_storage_live_locals`

Related to rust-lang#99021.

r?  `@JakobDegen` (as discussed on Zulip)

Add test for and fix rust-lang/rust-clippy#9131

This lint seems to have been broken by rust-lang#98446 -- but of course, there was no clippy test for this case at the time.

`expr.span.ctxt().outer_expn_data()` now has `MacroKind::Derive` instead of `MacroKind::Attr` for something like:

```
#[derive(Clone, Debug)]
pub struct UnderscoreInStruct {
    _foo: u32,
}
```

---

changelog: none

closes: rust-lang/rust-clippy#9131