don't leak internal temporaries from `dbg!`, even on false unwind paths by dianne · Pull Request #155915 · rust-lang/rust

dianne · 2026-04-28T11:18:55Z

Hopefully fixes #155902 for real this time! See #155902 (comment) and the following comments for why I think matching on a tuple of dbg!'s arguments seems not to be a viable implementation strategy. Instead, this uses super let to get better control over scoping, which unfortunately makes for pretty awkward code with the current version of super let.

One alternative to this would be reverting all the recent changes to dbg! for now and re-landing them once super let's replacement is usable. That will probably be the go-to answer for these tricky scoping problems.

Another alternative would be to change Rust's static semantics to (hopefully) make the match-based dbg! not a problem.

I also noticed std::macros::dbg_internal! seems to be stable in beta (playground), so I've taken the liberty of de-stabilizing it. I can pull that out into a separate PR later if that'd be better, but I figure if we revert the recent changes to dbg!, we'd also be reverting the addition of dbg_internal!, so for now that's here.

This may also need clippy and compiler review, but let's start with r? libs

rustbot · 2026-04-28T11:18:59Z

The Clippy subtree was changed

cc @rust-lang/clippy

apiraino · 2026-04-28T12:44:18Z

t-compiler will defer backport decision to t-libs since this is almost entirely in their purview

cuviper · 2026-04-28T18:01:14Z

Maybe it's worth a crater run compared to stable?

dianne · 2026-05-02T06:36:38Z

@bors try

don't leak internal temporaries from `dbg!`, even on false unwind paths

rust-bors · 2026-05-02T08:46:23Z

☀️ Try build successful (CI)
Build commit: 012cd62 (012cd62c9add58ab3910e44c137d87db3ab70f61, parent: 67bcaa9c4b1b1015efae3d591155c79760b1e0a5)

dianne · 2026-05-03T11:16:09Z

I guess for a crater run against stable, we'd need a branch with the commits from this, #154994, #154074, and #149869 cherry-picked? I'll try setting that up as a draft PR against stable.

cuviper · 2026-05-03T22:13:39Z

I just meant stable vs. this nightly -- which will include other changes, but that's true if we beta-backport too. I think we can just do this:

@craterbot check start=1.95.0

cuviper · 2026-05-03T22:14:27Z

@craterbot check start=1.95.0 end=try#012cd62c9add58ab3910e44c137d87db3ab70f61

craterbot · 2026-05-03T22:14:54Z

👌 Experiment pr-155915 created and queued.
🔍 You can check out the queue and this experiment's details.

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

cuviper · 2026-05-06T22:28:05Z

Bumping priority since this is release-relevant for 1.96-beta.

@craterbot name=pr-155915 p=1

craterbot · 2026-05-06T22:28:08Z

📝 Configuration of the pr-155915 experiment changed.

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

craterbot · 2026-05-08T14:43:13Z

🚧 Experiment pr-155915 is now running

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

craterbot · 2026-05-10T19:46:07Z

🎉 Experiment pr-155915 is completed!
📊 33251 regressed and 8603 fixed (918169 total)
📊 4415 spurious results on the retry-regressed-list.txt, consider a retry¹ if this is a significant amount.
📰 Open the summary report.

⚠️ If you notice any spurious failure please add them to the denylist!
ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

re-run the experiment with crates=https://crater-reports.s3.amazonaws.com/pr-155915/retry-regressed-list.txt ↩

dianne · 2026-05-10T21:37:39Z

that's a whole lotta errors from unstable features being removed or changed. in particular, lots from old versions of proc-macro2 using proc_macro_span_shrink when compiled with a nightly toolchain and old versions of ahash using stdsimd. of course, since we're comparing against stable, anything that only breaks when using nightly is going to show up as a "regression"

looks like no E0597 (value dropped while borrowed) at least? and searching for dbg! didn't turn up anything actually related to dbg!, as far as I could tell. the mentions of dbg! in regressed crates' build logs were all in warnings; the regressions were in deps (specifically proc-macro2 or ahash).

theemathas · 2026-05-11T14:18:39Z

I'm not in the libs team, but I personally think the simplest way to resolve this is:

Revert all the dbg!() changes (maybe except for tests).
Backport that revert to beta.
Open a new PR with this PR's contents (using super let) (against the main branch, not beta.)
Run a normal crater with that new PR.
If there are no issues, merge that PR, and have it ride the release train normally, starting from nightly.

workingjubilee · 2026-05-11T16:45:42Z

That honestly seems like the most reasonable approach. We can't keep throwing good money (or effort, I suppose) after bad like this. "Starting over" would let us at least scavenge some value from the work without a threat that regressions, which we probably don't actually understand the full scope of yet, hit stable any time soon.

nia-e · 2026-05-13T16:09:47Z

We discussed this in the libs meeting; we agree with @theemathas' suggestion of reverting everything (incl. on nightly) and re-landing the dbg changes

cuviper · 2026-05-15T00:20:42Z

See #156589 for a full revert.

These are all tests from trying to fix the tear-free `dbg!`: * #154074 * #154994 * #155915 These should also work as we revert to the old `dbg!`, so we should keep the tests to make sure they don't regress again. Co-authored-by: dianne <diannes.gm@gmail.com>

@joboet

Revert tearing changes to `dbg!` Since the primary change to `dbg!` in #149869, we've been chasing a few regressions: * #153850, fixed by #154074 * #154988, fixed by #154994 * #155902, proposed fix in #155915 We already reverted this once, on beta only to prevent these regressions from shipping in 1.95. In that most recent PR, we decided that it would be better to revert `dbg!` to its original state everywhere (`main` and 1.96-`beta`), and then we can consider it from scratch later. So here I've reverted the change and its fixes, but kept the regression tests, including the pending one. cc @joboet @dianne @rust-lang/libs @rustbot label beta-nominated

rust-bors · 2026-05-20T02:54:07Z

☔ The latest upstream changes (presumably #156589) made this pull request unmergeable. Please resolve the merge conflicts.

These are all tests from trying to fix the tear-free `dbg!`: * rust-lang#154074 * rust-lang#154994 * rust-lang#155915 These should also work as we revert to the old `dbg!`, so we should keep the tests to make sure they don't regress again. Co-authored-by: dianne <diannes.gm@gmail.com> (cherry picked from commit 6f35b83)

@joboet

Revert tearing changes to `dbg!` Since the primary change to `dbg!` in rust-lang/rust#149869, we've been chasing a few regressions: * rust-lang/rust#153850, fixed by rust-lang/rust#154074 * rust-lang/rust#154988, fixed by rust-lang/rust#154994 * rust-lang/rust#155902, proposed fix in rust-lang/rust#155915 We already reverted this once, on beta only to prevent these regressions from shipping in 1.95. In that most recent PR, we decided that it would be better to revert `dbg!` to its original state everywhere (`main` and 1.96-`beta`), and then we can consider it from scratch later. So here I've reverted the change and its fixes, but kept the regression tests, including the pending one. cc @joboet @dianne @rust-lang/libs @rustbot label beta-nominated

@joboet

Revert tearing changes to `dbg!` Since the primary change to `dbg!` in rust-lang/rust#149869, we've been chasing a few regressions: * rust-lang/rust#153850, fixed by rust-lang/rust#154074 * rust-lang/rust#154988, fixed by rust-lang/rust#154994 * rust-lang/rust#155902, proposed fix in rust-lang/rust#155915 We already reverted this once, on beta only to prevent these regressions from shipping in 1.95. In that most recent PR, we decided that it would be better to revert `dbg!` to its original state everywhere (`main` and 1.96-`beta`), and then we can consider it from scratch later. So here I've reverted the change and its fixes, but kept the regression tests, including the pending one. cc @joboet @dianne @rust-lang/libs @rustbot label beta-nominated

@joboet

Revert tearing changes to `dbg!` Since the primary change to `dbg!` in rust-lang/rust#149869, we've been chasing a few regressions: * rust-lang/rust#153850, fixed by rust-lang/rust#154074 * rust-lang/rust#154988, fixed by rust-lang/rust#154994 * rust-lang/rust#155902, proposed fix in rust-lang/rust#155915 We already reverted this once, on beta only to prevent these regressions from shipping in 1.95. In that most recent PR, we decided that it would be better to revert `dbg!` to its original state everywhere (`main` and 1.96-`beta`), and then we can consider it from scratch later. So here I've reverted the change and its fixes, but kept the regression tests, including the pending one. cc @joboet @dianne @rust-lang/libs @rustbot label beta-nominated

Mark-Simulacrum · 2026-06-06T18:39:39Z

Coming back to this... I think this is not in its current state needed, because we fully removed the dbg! no tearing implementation, right? Should we close it and then it (or an alternative) can be incorporated into a future PR changing dbg! again, if we go ahead with that?

@joboet

Revert tearing changes to `dbg!` Since the primary change to `dbg!` in rust-lang/rust#149869, we've been chasing a few regressions: * rust-lang/rust#153850, fixed by rust-lang/rust#154074 * rust-lang/rust#154988, fixed by rust-lang/rust#154994 * rust-lang/rust#155902, proposed fix in rust-lang/rust#155915 We already reverted this once, on beta only to prevent these regressions from shipping in 1.95. In that most recent PR, we decided that it would be better to revert `dbg!` to its original state everywhere (`main` and 1.96-`beta`), and then we can consider it from scratch later. So here I've reverted the change and its fixes, but kept the regression tests, including the pending one. cc @joboet @dianne @rust-lang/libs @rustbot label beta-nominated

dianne · 2026-06-07T14:54:38Z

yeah. I've opened a clean PR for this approach to avoiding tearing in dbg! in case we still want to go ahead with it: #157576. closing this in favor of that.

@joboet

Revert tearing changes to `dbg!` Since the primary change to `dbg!` in rust-lang/rust#149869, we've been chasing a few regressions: * rust-lang/rust#153850, fixed by rust-lang/rust#154074 * rust-lang/rust#154988, fixed by rust-lang/rust#154994 * rust-lang/rust#155902, proposed fix in rust-lang/rust#155915 We already reverted this once, on beta only to prevent these regressions from shipping in 1.95. In that most recent PR, we decided that it would be better to revert `dbg!` to its original state everywhere (`main` and 1.96-`beta`), and then we can consider it from scratch later. So here I've reverted the change and its fixes, but kept the regression tests, including the pending one. cc @joboet @dianne @rust-lang/libs @rustbot label beta-nominated

@joboet

Revert tearing changes to `dbg!` Since the primary change to `dbg!` in rust-lang/rust#149869, we've been chasing a few regressions: * rust-lang/rust#153850, fixed by rust-lang/rust#154074 * rust-lang/rust#154988, fixed by rust-lang/rust#154994 * rust-lang/rust#155902, proposed fix in rust-lang/rust#155915 We already reverted this once, on beta only to prevent these regressions from shipping in 1.95. In that most recent PR, we decided that it would be better to revert `dbg!` to its original state everywhere (`main` and 1.96-`beta`), and then we can consider it from scratch later. So here I've reverted the change and its fixes, but kept the regression tests, including the pending one. cc @joboet @dianne @rust-lang/libs @rustbot label beta-nominated

@joboet

Revert tearing changes to `dbg!` Since the primary change to `dbg!` in rust-lang/rust#149869, we've been chasing a few regressions: * rust-lang/rust#153850, fixed by rust-lang/rust#154074 * rust-lang/rust#154988, fixed by rust-lang/rust#154994 * rust-lang/rust#155902, proposed fix in rust-lang/rust#155915 We already reverted this once, on beta only to prevent these regressions from shipping in 1.95. In that most recent PR, we decided that it would be better to revert `dbg!` to its original state everywhere (`main` and 1.96-`beta`), and then we can consider it from scratch later. So here I've reverted the change and its fixes, but kept the regression tests, including the pending one. cc @joboet @dianne @rust-lang/libs @rustbot label beta-nominated

* migrate generate_trait_from_impl * missing pause * Prepare for merging from rust-lang/rust This updates the rust-version file to 30d0309. * sembr src/appendix/code-index.md * re-wrap * sembr src/const-eval/interpret.md * whitespace * sembr src/traits/separate-projection-bounds.md * slight improvements * skipped by sembr tool (due to "e.g.") * sembr src/ty-module/generic-arguments.md * re-wrap * sembr src/hir.md * re-wrap * sembr src/rustdoc-internals.md * re-wrap * sembr src/tests/adding.md * re-flow * add whitespace heuristics same as ted to SyntaxEditor via insert_with_whitespace and insert_all_with_whitespace * update insert_use_with_editor_ to make use of whitespace heuristics * migrate extract_struct_from_enum_variant to SyntaxEditor and SyntaxFactory * lets use syntaxFactory in migration as well * Use RA_TEST_ prefix in env test to avoid collisions with process env * Fix [env] in .cargo/config.toml overriding process environment variables cargo_config_env() only checked extra_env (rust-analyzer.cargo.extraEnv) when deciding whether to skip an existing variable, but never checked the actual process environment via std::env::var. This caused config.toml values to unconditionally override real environment variables even without force = true, diverging from Cargo's behavior. Additionally, plain string entries (e.g. `KEY = "value"`) skipped the force check entirely. When a process env var takes precedence, its value is now inserted into the Env so that env!/option_env! resolution stays correct. Fixes rust-lang/rust-analyzer#21994 * Add test for process env variable precedence over config.toml [env] * Fix platform-specific stderr mismatch in ice_contract_attr_on_eii_generated_item test The previous test used `fn implementation() {}` with a body, which caused `generate_default_impl` to generate a `const _: () = { fn implementation() {} }` item containing `self::implementation`. On Linux (aarch64-gnu-llvm-21), the resolver's `suggest_ident_hidden_by_hygiene` emitted an extra help span on the resulting E0425 error that did not appear on macOS, causing a stderr mismatch. Switch the declaration to `fn implementation();` (no body) so that `generate_default_impl` is not called and no `self::implementation` path is emitted. The test still validates that `#[eii]` + `#[core::contracts::ensures]` produces graceful errors instead of an ICE, via the two contract-annotation errors on the generated foreign item. * add get_or_create_assoc_item_list editor variant * replace make with SyntaxEditor in generate_single_field_struct_from * Use fine grained component-wise span tracking in use trees * Use the item span for DefKind::Use, it is never used anyway * remove unnecessary variables and delimiter check * drive-by cleanup * suppress unreachable code lint in automatically derived impls This is relevant for `derive(Clone, PartialEq)` on adts with fields of type never. * Parenthesize block-like expressions in index base of pretty printer The AST pretty printer produces invalid Rust when a block expression is the base of an index operation inside a macro expansion. This is a gap in the existing `FixupContext` parenthesization machinery — the approach handles statement position but not the case where a block-index is nested inside another expression. The following is a correct program: ```rust macro_rules! block_arr { () => {{ [0u8; 4] }}; } macro_rules! as_slice { () => {{ &block_arr!()[..] }}; } fn main() { let _: &[u8] = as_slice!(); } ``` But `rustc -Zunpretty=expanded` produces output that is not valid Rust, because the closing brace of `{ [0u8; 4] }` creates a statement boundary, causing the parser to treat `[..]` as a separate expression: ```rust fn main() { let _: &[u8] = { &{ [0u8; 4] }[..] }; } ``` ``` error: expected one of `.`, `;`, `?`, `}`, or an operator, found `[` ``` Fixed output after this change: ```rust fn main() { let _: &[u8] = { &({ [0u8; 4] })[..] }; } ``` Since `{ ... }[...]` never parses as indexing a block regardless of context, the fix unconditionally parenthesizes "complete" expressions (block, match, if, loop, etc.) when they appear as the base of an index operation. * Parenthesize block-like expressions in call callee of pretty printer When a macro expands to a call whose callee is a block (or other "complete" expression like `match`, `if`, `loop`), the AST pretty printer emits the callee without parentheses. In statement position the closing brace ends the expression and the argument list is parsed as a separate tuple expression, producing a parse error. * rename test * Cargo submodule update * Nooooo my workflow relied on programs using `niko` as an identifier being faster to compile :sob: * make `expected_literal` positive * internal: add workflow to handle generating lints * compiletest: pass -Zunstable-options for unpretty and no-codegen paths Unconditionally pass -Zunstable-options in the `unpretty` and `-Zno-codegen` (typecheck) paths in compiletest. This ensures custom targets resolved via RUST_TARGET_PATH work consistently. This is primarily needed when using non-built-in targets without a .json extension. Signed-off-by: Deepesh Varatharajan <Deepesh.Varatharajan@windriver.com> * min/max_by tests: also check result * Clarify old solver behavior with revisions in a test * renaming method is_impl_trait to is_opaque * Use the trait object's own bounds instead of goal when considering builtin object bounds * Clarify that `core::range::RangeInclusive` does not have special syntax I'm ignoring the fact that there's a feature to change the behavior of the syntax. I just want to help prevent confusing the people reading the docs. * Clarify that `core::range::{Range,RangeFrom,RangeToInclusive}` do not have special syntax I'm ignoring the fact that there's a feature to change the behavior of the syntax. I just want to help prevent confusing the people reading the docs. * Break a single query cycle in the deadlock handler * Fix feature name for unstable `integer_extend_truncate` functions The feature name for the const unstable attribute was accidentally transposed when const traits were added. * meta: Add checkboxes to unsresolved questions in issue templates These frequently have links to comments on closed PRs, meaning it can looks like issues have been resolved even if that isn't the case. Add checkboxes to make it more clear when a conclusion has been reached. * fixing clippy reference * Update tracking issue number of future-incompatibility lint `unstable_syntax_pre_expansion` * Move `maybe_loop_headers` out of `rustc_middle`. `rustc_middle` is enormous and it's always good to move things out of it where possible. `maybe_loop_headers` is easy to move because it has a single use in `jump_threading.rs`. * Fix ICE in next-solver TransmuteFrom candidate Treat TransmuteFrom goals with non-region inference variables as ambiguous before running transmutability, instead of computing layouts for unresolved types. The old solver already treated these goals as ambiguous, so only the next solver could hit this ICE. * refactor rustc_hir_typeck/src/op.rs * Add a test for an LLVM crash "Vector elements must have same size" * Add a test for a const evaluator ICE on a self-receiver type mismatch * Add a codegen test for a missed optimisation with spare niches * Disable the fix for missing-fields when the fields are private * Revert performing basic const checks in typeck on stable * remove create-struct-def subeditors we don't need them and can use make constructor directly * Fix cycles during delayed lowering * minor follow up to removing soft mode `#[unstable]` * Implement `GenericTypeVisitable` for some types This is required for rust-analyzer. * Fix code block whitespace handling * Update cargo submodule * Fix if branch in op.rs * Fix tabs in test file to satisfy tidy check * Prepare for merging from rust-lang/rust This updates the rust-version file to 4c42051. * main-termination * Replacing `self` overwriting with proper resolution * Add test for trailing self * Bless other tests * Revert rust-lang#154808 because it is based on rust-lang#152369 This reverts commit 0c94559, reversing changes made to 3352861. * Revert rust-lang#152369 because of multiple regressions The regressions are documented in the PR comments. This reverts commit 2972b5e, reversing changes made to f908263. * Regression test for issue 154878 Co-authored-by: Edvin Bryntesson <epost@edvinbryntesson.se> * Regression test for issue 154800 Co-authored-by: Edvin Bryntesson <epost@edvinbryntesson.se> * Regression test for issue 155008 Co-authored-by: Edvin Bryntesson <epost@edvinbryntesson.se> * Add (failing) ui test for denying global_allocator + thread_local * Deny global_allocator + thread_local * Update ui test for deny global_allocator + thread_local * Improve diagnostic for global_allocator + thread_local * Apply suggestions from fmt output * Set the Fuchsia ABI to the documented minimum Fuchsia only supports the RVA22 + vector as its minimum ABI for RISC-V. https://fuchsia.dev/fuchsia-src/contribute/governance/rfcs/0234_riscv_abi_rva22+vector * Move the `cache_on_disk` check out of `try_load_from_disk_fn`. It doesn't need to be in there, it can instead be at the single call site. Removing it eliminates one parameter, makes `define_queries!` smaller (which is always good), and also enables the next commit which tidies up profiling. This commit also changes how `value` and `verify` are initialized, because I don't like the current way of doing it after the declaration. * Move profiling of query loading outwards. From `plumbing.rs` to `execution.rs`, which is where most of the other query profiling occurs. It also avoids eliminates some fn parameters. This means the `provided_to_erased` call in `try_from_load_disk_fn` is now included in the profiling when previously it wasn't. This is good because `provided_to_erased` is included in other profiling calls (e.g. calls to `invoke_provider_fn`). * Fix unelided lifetime ICE, refactoring of GenericArgPosition * Introduce a `#[diagnostic::on_unknown_item]` attribute This PR introduces a `#[diagnostic::on_unknown_item]` attribute that allows crate authors to customize the error messages emitted by unresolved imports. The main usecase for this is using this attribute as part of a proc macro that expects a certain external module structure to exist or certain dependencies to be there. For me personally the motivating use-case are several derives in diesel, that expect to refer to a `tabe` module. That is done either implicitly (via the name of the type with the derive) or explicitly by the user. This attribute would allow us to improve the error message in both cases: * For the implicit case we could explicity call out our assumptions (turning the name into lower case, adding an `s` in the end) + point to the explicit variant as alternative * For the explicit variant we would add additional notes to tell the user why this is happening and what they should look for to fix the problem (be more explicit about certain diesel specific assumptions of the module structure) I assume that similar use-cases exist for other proc-macros as well, therefore I decided to put in the work implementing this new attribute. I would also assume that this is likely not useful for std-lib internal usage. * Address review comments * Rename the attribute to `on_unknown` * introduce TypingModeEqWrapper and make TypingMode !Eq * make typing_mode getter * add `#[rustc_must_match_exhaustively]` * Rename `#[rustc_layout]` to `#[rustc_dump_layout]` * Rename `#[rustc_dump_layout]`'s `abi` option to `backend_repr` Moreover, dereference `ty_layout.align` for `#[rustc_dump_layout(align)]` to render `align: Align($N bytes)` instead of `align: AbiAlign { abi: Align($N bytes) }` which contains the same amount of information but it more concise and legible. * Rename `#[rustc_hidden_type_of_opaques]` to `#[rustc_dump_hidden_type_of_opaques]` * Rename `#[rustc_def_path]` to `#[rustc_dump_def_path]` * Rename `#[rustc_symbol_name]` to `#[rustc_dump_symbol_name]` * Simplify impl of `dump_symbol_names_and_def_paths` * make all typing-mode conditional code an exhaustive match * Make `rustc_attr_parsing::SharedContext::emit_lint` take a `MultiSpan` instead of a `Span` * fixup rustdoc,clippy,rustfmt * Reject dangling attributes in where clauses * Apply replace-version-placeholder * Switch channel to beta * Patch musl's CVE-2026-6042 and CVE-2026-40200 - [CVE-2026-6042] is a denial of service in `iconv`. - [CVE-2026-40200] is an out-of-bounds write in `qsort`. Neither is relevant to Rust itself, but they could be used in mixed- language projects that link with our `self-contained/libc.a`. [CVE-2026-6042]: https://www.openwall.com/lists/oss-security/2026/04/09/19 [CVE-2026-40200]: https://www.openwall.com/lists/musl/2026/04/10/3 * Revert "Build shared LLVM lib for windows-gnullvm" This reverts commit 1d1280a. Looks like this causes problems with certain LLVM bin tools not finding `libLLVM` on `*-windows-gnullvm`. This commit is a _minimal_ revert to return us to known state to alleviate time pressure to investigate. * [beta-1.96] Update cargo submodule * don't leak internal temporaries from `dbg!` (cherry picked from commit 35be9f2) * fix arch names in cfg pretty printer (cherry picked from commit 05081b9) * Bump beta stage0 to released 1.95.0 This also re-adds assert_matches features everywhere. * Add temporary scope to assert_matches Addresses rust-lang#154406 in part. assert_eq will be done in a separate PR. (cherry picked from commit e0ef87f) * Apply review feedback (cherry picked from commit 3a0c0e9) * fix: ✏️ forgot to change the stable version for `assert_matches!` macro. (cherry picked from commit a449ea5) * fix: adding missing corrections (cherry picked from commit 910e2d2) * codegen-options docs: remove -Csoft-float (cherry picked from commit 02a8982) * Fix passing paths with space into dlltool (cherry picked from commit 23c7bf0) * Test that raw-dylib works with whitespace paths (cherry picked from commit 6d20c98) * resolve: Set correct parent and expansion for `self` declarations (cherry picked from commit 16729bc) * Fix unused assignments in diverging branches (cherry picked from commit 64e9326) * Update cargo submodule * Remove broken dilos apt repo CI is currently down because apt is unable to access the repo at dilos.org. It is failing inside the fortanix install script which tries to run apt-get with the error: ``` 5.679 E: Failed to fetch https://apt.dilos.org/dilos/dists/dilos2/InRelease 403 Forbidden [IP: 116.202.240.188 443] ``` These lines in the Dockerfile were added when Solaris builds were merged into dist-various-2 in rust-lang#45001. However, Solaris builds were split off in rust-lang#138699. In that PR, these lines adding the dilos repository weren't removed. AFAICT, these are no longer necessary. * Revert "Rollup merge of rust-lang#154994 - dianne:no-dbg-temp, r=Mark-Simulacrum" This reverts commit 59b36a5, reversing changes made to 197eb8c. (cherry picked from commit 73931c4) * Revert "Rollup merge of rust-lang#154074 - dianne:dbg-temp-scopes, r=Mark-Simulacrum" This reverts commit 2a18b88, reversing changes made to cd14b73. (cherry picked from commit c9d9448) * Revert "Rollup merge of rust-lang#149869 - joboet:torn-dbg, r=Mark-Simulacrum" This reverts commit cc666ba, reversing changes made to 2da5959. (cherry picked from commit 9246e19) * Restore `dbg!` regression tests These are all tests from trying to fix the tear-free `dbg!`: * rust-lang#154074 * rust-lang#154994 * rust-lang#155915 These should also work as we revert to the old `dbg!`, so we should keep the tests to make sure they don't regress again. Co-authored-by: dianne <diannes.gm@gmail.com> (cherry picked from commit 6f35b83) * Add MSRV check for `manual_noop_waker` (rust-lang#16850) Fixes rust-lang/rust-clippy#16849 changelog: [`manual_noop_waker`]: Add MSRV check * Fixes a case where `collapsible_match` suggested a transformation that changes runtime behavior. (rust-lang#16878) Closes rust-lang/rust-clippy#16875 ### What was wrong The lint suggested collapsing `pattern => { if test { body } }` into `pattern if test => { body }`. These are not equivalent. In the original, once `pattern` matches, the match exits regardless of `test`. In the suggestion, a failing guard allows fall-through to subsequent arms, which can match values that previously never reached them. ```rust // Before (original) match a { Some(_) => { if b == 0 { res = 1 } } _ if b == 1 => res = 2, // unreachable when a is Some(_) _ => {} } // After (suggestion — WRONG, changes behavior) match a { Some(_) if b == 0 => res = 1, _ if b == 1 => res = 2, // now reachable when a is Some(_) and b != 0 _ => {} } ``` ### Fix The `if`-guard collapsing is only safe when there are no non-wildcard arms between the current arm and the wildcard arm. The fix adds a check that all arms after the current one are "wild-like" (a bare `_`, a binding, or `None`, all without guards) before suggesting the transformation. As a side effect, three `#[expect(clippy::collapsible_match)]` suppressions in `clippy_lints/src/methods/mod.rs` are removed. They had been added to suppress this exact false positive and are no longer needed. ### Still lints correctly When only wildcard arms follow, the transformation is safe and the lint still fires: ```rust // This still lints — only `_ => {}` follows, fall-through is harmless match a { Some(_) => { if b == 0 { res = 1 } // triggers collapsible_match } _ => {} } ``` changelog: [`collapsible_match`]: no longer suggests collapsing `pattern => { if test { body } }` into a match guard when non-wildcard arms follow, as this changes the semantics of the match.   ### Summary Notes - [Beta-nomination](rust-lang/rust-clippy#16878 (review)) by [samueltardieu](https://github.com/samueltardieu) *Managed by `@rustbot`—see [help](https://forge.rust-lang.org/triagebot/note.html) for details*   * Update cargo for CVE-2026-5222 and CVE-2026-5223 * Sync relnotes for 1.96.0 This copies every change from `main` and rust-lang#156932. * Bump to stable release * Upgrade to Rust 1.96.0 and adapt BlueOS targets for the new toolchain (#12) * [BlueOS] Support vivo BlueOS Adapted to Rust 1.96 when resolving conflicts: - Migrate cfg_if! to cfg_select! in sys/ modules - Move blueos cfg entries from pal/unix/os.rs to sys/paths/unix.rs - Move blueos cfg entries from pal/unix/process/ to sys/process/unix/ - Add blueos to pal/unix/sync/condvar.rs cfg lists - Add blueos to fs/unix.rs link() no-linkat fallback (cherry picked from commit 443b4ca) * Update config.blueos.toml for MacOS. (#2) Description: Fix mac toolchain error Reason: ``` ./x.py install -i --stage 1 library/std --target thumbv8m.main-vivo-blueos-newlibeabihf compile error on MacOS ``` Issue: NA * Strip binaries to avoid exhausting runner's space (#3) So that we can largely reduce artifacts' size and not exhaust github action runner's space. * feat: Build sanitizers on Linux and Darwin (#4) * fix: rv32imc on BlueOS should use emutls at the moment (#5) Same as rv32imac on BlueOS. * feat: Use PIC relocation model by default (#6) We need a libcore with PIC enabled to build static PIE. * Don't build clang to save time (#8) clang is installed via the package manager. * Support dynlink and pic on cortex-m (#9) * Fix: bootstrap abi issue Adapted to Rust 1.96 when resolving conflicts: - Migrate cfg_if! to cfg_select! in os/unix/process.rs - Move blueos stat time accessors from scalar (st_atime/st_mtime/st_ctime) to timespec (st_atim/st_mtim/st_ctim) in sys/fs/unix.rs - Add blueos to sys/process/unix/mod.rs allow(unused) cfg_attr (cherry picked from commit 7dd0ed8) * Remove potential GPL components Adapted to Rust 1.96 when resolving conflicts: - mingw-check/ was reorganized to pr-check-1/ upstream - Remove pr-check-1/ directory (Dockerfile, reuse-requirements, etc.) - Remove pr-check-1/ references from tidy/Dockerfile (cherry picked from commit 6e2ebcb) * fix: update BlueOS libc fork pin and adapt to Rust 1.96 Pin the BlueOS libc fork to commit 2f8715c4 (adapt libc to Rust 1.96 toolchain) in Cargo.lock, library/Cargo.lock and tidy ALLOWED_SOURCES. Adjust BlueOS target specs and std sources for the 1.96 upgrade: - Update target spec fields for the new target-spec API - Set c_char to i8 on BlueOS targets (-fsigned-char) - Adapt std/sys/pal/unix and std/os/blueos to the 1.96 layout - Bump bootstrap and profiler_builtins Cargo metadata * style: apply rustfmt to BlueOS target specs and std code * Migrate BlueOS libc/cc-rs forks to vivoblueos repo --------- Co-authored-by: Kai Law <lawkai@vivo.com> Co-authored-by: Kane <hecheng@vivo.com> Co-authored-by: zhanghe-vivo <zhanghe9702@vivo.com> * Use 1.96.0-adapted libc/cc-rs branches for toolchain CI Switch libc/cc-rs from blueos-dev to the version-tagged branches (v0.2.183 / v1.2.28) that are adapted for Rust 1.96.0, and regenerate the lock files accordingly. * Use pic relocation model and dynlink by default for v1.96 (#15) * feat: Use pic relocation model and dynlink by default at v1.96 * Enable rust-lld for mac --------- Signed-off-by: Deepesh Varatharajan <Deepesh.Varatharajan@windriver.com> Co-authored-by: bit-aloo <sshourya17@gmail.com> Co-authored-by: Jacob Pratt <jacob@jhpratt.dev> Co-authored-by: bors <bors@rust-lang.org> Co-authored-by: Tshepang Mbambo <hopsi@tuta.io> Co-authored-by: The rustc-josh-sync Cronjob Bot <github-actions@github.com> Co-authored-by: smihica <smihica@gmail.com> Co-authored-by: GokhanKabar <gokhankabar@hotmail.fr> Co-authored-by: Oli Scherer <github@oli-obk.de> Co-authored-by: b1yd <2156864690@qq.com> Co-authored-by: A4-Tacks <wdsjxhno1001@163.com> Co-authored-by: Waffle Lapkin <waffle.lapkin@gmail.com> Co-authored-by: Andrew V. Teylu <andrew.teylu@vector.com> Co-authored-by: Jonathan Brouwer <jonathantbrouwer@gmail.com> Co-authored-by: Weihang Lo <me@weihanglo.tw> Co-authored-by: Jana Dönszelmann <jana@donsz.nl> Co-authored-by: dybucc <149513579+dybucc@users.noreply.github.com> Co-authored-by: Deepesh Varatharajan <Deepesh.Varatharajan@windriver.com> Co-authored-by: Laurențiu Nicola <lnicola@users.noreply.github.com> Co-authored-by: Ralf Jung <post@ralfj.de> Co-authored-by: Shoyu Vanilla <modulo641@gmail.com> Co-authored-by: Jose <Jose.Torres6@aexp.com> Co-authored-by: Jake Goulding <jake.goulding@gmail.com> Co-authored-by: John Kåre Alsaker <john.kare.alsaker@gmail.com> Co-authored-by: okaneco <47607823+okaneco@users.noreply.github.com> Co-authored-by: Trevor Gross <tg@trevorgross.com> Co-authored-by: León Orell Valerian Liehr <me@fmease.dev> Co-authored-by: Chayim Refael Friedman <chayimfr@gmail.com> Co-authored-by: Nicholas Nethercote <n.nethercote@gmail.com> Co-authored-by: cijiugechu <cijiugechu@gmail.com> Co-authored-by: malezjaa <poreba.kris@gmail.com> Co-authored-by: Lukas Wirth <me@lukaswirth.dev> Co-authored-by: Jacob Adam <software@jacobadam.net> Co-authored-by: Oli Scherer <rust@oli-obk.de> Co-authored-by: aerooneqq <aerooneq@yandex.ru> Co-authored-by: Pavan <pavankumaryalagada@gmail.com> Co-authored-by: Laurențiu Nicola <lnicola@dend.ro> Co-authored-by: xonx <119700621+xonx4l@users.noreply.github.com> Co-authored-by: mu001999 <mu001999@outlook.com> Co-authored-by: Edvin Bryntesson <epost@edvinbryntesson.se> Co-authored-by: Fayti1703 <hello@fayti1703.me> Co-authored-by: Paul Kirth <paulkirth@google.com> Co-authored-by: Georg Semmler <github@weiznich.de> Co-authored-by: Guillaume Gomez <contact@guillaume-gomez.fr> Co-authored-by: Mark Rousskov <mark.simulacrum@gmail.com> Co-authored-by: Josh Stone <jistone@redhat.com> Co-authored-by: Jieyou Xu <jieyouxu@outlook.com> Co-authored-by: dianne <diannes.gm@gmail.com> Co-authored-by: usamoi <usamoi@outlook.com> Co-authored-by: Lukas Bergdoll <lukas.bergdoll@gmail.com> Co-authored-by: romandev <84428770+romancitodev@users.noreply.github.com> Co-authored-by: Chris Denton <chris@chrisdenton.dev> Co-authored-by: Vadim Petrochenkov <vadim.petrochenkov@gmail.com> Co-authored-by: yukang <moorekang@gmail.com> Co-authored-by: Eric Huss <eric@huss.org> Co-authored-by: Samuel Tardieu <sam@rfc1149.net> Co-authored-by: Kai Law <lawkai@vivo.com> Co-authored-by: Kane <hecheng@vivo.com> Co-authored-by: zhanghe-vivo <zhanghe9702@vivo.com> Co-authored-by: zhaowenbo-vivo <zhaowenbo@vivo.com> Co-authored-by: Shi Hange - vivo <hangge.shi@vivo.com>

de-stabilize std::macros::dbg_internal!

f337562

rustbot assigned Mark-Simulacrum Apr 28, 2026

dianne commented Apr 28, 2026

View reviewed changes

Comment thread library/std/src/lib.rs Resolved

reimplement dbg! with super let

b896b20

dianne force-pushed the dbg-via-super-let branch from d0ae98f to b896b20 Compare April 28, 2026 11:59

This comment has been minimized.

Sign in to view

rust-bors Bot pushed a commit that referenced this pull request May 2, 2026

Auto merge of #155915 - dianne:dbg-via-super-let, r=<try>

012cd62

don't leak internal temporaries from `dbg!`, even on false unwind paths

dianne mentioned this pull request May 3, 2026

[do not merge] crater dbg! changes against stable-1.95.0 #156106

Closed

This comment was marked as resolved.

Sign in to view

craterbot added S-waiting-on-crater Status: Waiting on a crater run to be completed. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 3, 2026

craterbot removed the S-waiting-on-crater Status: Waiting on a crater run to be completed. label May 10, 2026

craterbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label May 10, 2026

apiraino mentioned this pull request May 14, 2026

1.96 beta regression: "lua does not live long enough", take 2 #155902

Closed

cuviper mentioned this pull request May 15, 2026

Revert tearing changes to dbg! #156589

Merged

theemathas mentioned this pull request May 15, 2026

dbg! prints can tear in multi-threading code #136703

Open

cuviper removed the beta-nominated Nominated for backporting to the compiler in the beta channel. label May 25, 2026

dianne mentioned this pull request Jun 7, 2026

avoid tearing dbg! prints, implemented using super let #157576

Closed

dianne closed this Jun 7, 2026

rustbot removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jun 7, 2026

Mark-Simulacrum mentioned this pull request Jul 16, 2026

Temporary lifetime testing strategy #159358

Open

Conversation

dianne commented Apr 28, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Apr 28, 2026

Uh oh!

Uh oh!

apiraino commented Apr 28, 2026

Uh oh!

cuviper commented Apr 28, 2026

Uh oh!

dianne commented May 2, 2026

Uh oh!

This comment has been minimized.

rust-bors Bot commented May 2, 2026

Uh oh!

dianne commented May 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

cuviper commented May 3, 2026

Uh oh!

This comment was marked as resolved.

cuviper commented May 3, 2026

Uh oh!

craterbot commented May 3, 2026

Uh oh!

cuviper commented May 6, 2026

Uh oh!

craterbot commented May 6, 2026

Uh oh!

craterbot commented May 8, 2026

Uh oh!

craterbot commented May 10, 2026

Footnotes

Uh oh!

dianne commented May 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

theemathas commented May 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

workingjubilee commented May 11, 2026

Uh oh!

nia-e commented May 13, 2026

Uh oh!

cuviper commented May 15, 2026

Uh oh!

rust-bors Bot commented May 20, 2026

Uh oh!

Mark-Simulacrum commented Jun 6, 2026

Uh oh!

dianne commented Jun 7, 2026

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

10 participants

dianne commented Apr 28, 2026 •

edited by rustbot

Loading

dianne commented May 3, 2026 •

edited

Loading

dianne commented May 10, 2026 •

edited

Loading

theemathas commented May 11, 2026 •

edited

Loading