Conversation
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>
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```
…r=yaahc Stabilize `into_future` rust-lang#67644 has been labeled with [S-tracking-ready-to-stabilize](https://github.com/rust-lang/rust/labels/S-tracking-ready-to-stabilize) - which mentions someone needs to file a stabilization PR. So hence this PR! ✨ Thanks! Closes rust-lang#67644 r? ``@joshtriplett``
…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``
Add doc comments in `rustc_middle::mir`
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
|
@bors r+ rollup=never p=6 |
|
☀️ Test successful - checks-actions |
|
Finished benchmarking commit (0f97e02): comparison url. Instruction count
Max RSS (memory usage)Results
CyclesResults
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression Footnotes |
|
Looks to be a genuine regression, far exceeding the noise bound for the deeply-nested-multi benchmark. (This is the 4% spike on that graph). Maybe caused by #98795? That looks to be moving some potentially sensitive code around, maybe needs some inlining help. cc @jackh726 |
Successful merges:
-Zterminal-widthas--diagnostic-width#95635 (sess: stabilize--terminal-widthas--diagnostic-width)into_future#98718 (Stabilizeinto_future)download-rustc = true#98798 (Fix caching bug indownload-rustc = true)rustc_middle::mir#99019 (Add doc comments inrustc_middle::mir)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup