Rollup of 9 pull requests #99039
Closed
Rollup of 9 pull requests #99039
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
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 <david.wood@huawei.com>
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 <david.wood@huawei.com>
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 <david.wood@huawei.com>
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.
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
rustbot
added
T-compiler
|
@bors r+ rollup=never p=10 |
bors
added
the
S-waiting-on-bors
|
⌛ Testing commit 32a2920 with merge 756e34437a19768f2e4c9bc1e3cc1ee70552b19e... |
|
💔 Test failed - checks-actions |
bors
added
S-waiting-on-review
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
☔ The latest upstream changes (presumably #98482) made this pull request unmergeable. Please resolve the merge conflicts. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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:
-Zterminal-widthas--diagnostic-width#95635 (sess: stabilize--terminal-widthas--diagnostic-width)-Zdump-drop-tracking-cfgdebugging flag #98533 (Add a-Zdump-drop-tracking-cfgdebugging flag)let_chainsblocker #98633 (Fix lastlet_chainsblocker)download-rustc = true#98798 (Fix caching bug indownload-rustc = true)rustc_middle::mir#99019 (Add doc comments inrustc_middle::mir)always_storage_live_locals#99022 (MIR dataflow: Rename function toalways_storage_live_locals)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup