Relocate issues/issue-51154.rs to closures/box-generic-closure.rs
Relocate issues/issue-51515.rs to
borrowck/assignment-to-immutable-ref.rs
Relocate issues/issue-53348.rs to mismatched_types/deref-string-assign.rs
Relocate issues/issue-52717.rs to
pattern/match-enum-struct-variant-field-missing.rs
Relocate issues/issue-53300.rs to
type/cannot-find-wrapper-with-impl-trait.rs
Update cargo submodule
7 commits in 9fa462fe3a81e07e0bfdcc75c29d312c55113ebb..2a7c4960677971f88458b0f8b461a866836dff59
2025-11-21 20:49:51 +0000 to 2025-11-25 19:58:07 +0000
- docs(config-include): prepare for doc stabilization (rust-lang/cargo#16301)
- fix(config-include): remove support of single string shorthand (rust-lang/cargo#16298)
- Revert "feat: Do not lock the artifact-dir for check builds" (rust-lang/cargo#16299)
- clean: Add --workspace support (rust-lang/cargo#16263)
- feat(tree): Add more native completions (rust-lang/cargo#16296)
- fix(package): exclude target/package from backups (rust-lang/cargo#16272)
- test: re-enable test since not flaky anymore (rust-lang/cargo#16287)
Simplify OnceCell Clone impl
Noticed when developing https://github.com/fast/mea/pull/79.
This may also apply to `OnceLock`. But unfortunately, we can't construct a completed `Once` beforehand.
Note that `OnceCell::from` is marked as [`rustc_const_unstable`](https://github.com/rust-lang/rust/issues/143773) so we don't need an extra `const fn from_value` to leverage possible const convert benefit.
Fix comment wording in simplify_comparison_integral.rs
This change corrects the wording in a comment within `simplify_comparison_integral.rs`, changing "user" to "used" to accurately describe that a moved value cannot be used later on.
The adjustment improves code documentation clarity while maintaining consistency with our standards for precise terminology in comments.
Fix invalid link generation for type alias methods
Fixes https://github.com/rust-lang/rust/issues/149205.
That one was quite the wild ride. First commit is the actual fix, the second commit is just a small name variable improvement while I was going through the code. Anyway, let's go through it:
* We don't generate directly implementations in the HTML files for local impls (which I think is a mistake and should be changed, gonna do that as a follow-up) but instead generate a JS file for each type alias containing the HTML for these impls.
* So in `write_shared.rs::TypeAliasPart::get`, when generating the JS file, we generate the impl into a `String` by calling `render_impl`. This method expects an `AssocItemLink` to help it generate the correct link to the item (I'm planning to also remove this enum because it's yet another way to generate anchors/hrefs).
* Problem was: we call the `provided_trait_methods` method on the impl item... which is empty if not a trait impl. This becomes an issue when we arrive in `render::assoc_href_attr` because of this code:
```rust
AssocItemLink::GotoSource(did, provided_methods) => {
let item_type = match item_type {
ItemType::Method | ItemType::TyMethod => {
if provided_methods.contains(&name) {
ItemType::Method
} else {
ItemType::TyMethod
}
}
item_type => item_type,
};
// ...
}
```
Since `provided_methods` is always empty, it means all methods on type aliases will be `TyMethod`, generating `#tymethod.` URLs instead of `#method.`.
* So generating `AssocItemLink::GoToSource` only on traits (when `provided_trait_methods` is supposed to return something) was the fix.
* And finally, because it's (currently) generating implementations only through JS, it means we cannot test it in `tests/rustdoc` so I had to write the test in `tests/rustdoc-gui`. Once I change how we generate local implementations for type aliases, I'll move it to `tests/rustdoc`.
r? ```@lolbinarycat```
add implementation-internal namespace for globalasm
Fixesrust-lang/rust#138261
Adds a namespace for `global_asm` with a lowercase letter which [is reserved for implementation-internal disambiguation](https://doc.rust-lang.org/rustc/symbol-mangling/v0.html#namespace:~:text=Lowercase%20letters%20are%20reserved%20for%20implementation%2Dinternal%20disambiguation%20categories%20(and%20demanglers%20should%20never%20show%20them)):
> Lowercase letters are reserved for implementation-internal disambiguation categories (and demanglers should never show them)
As a implementation-internal disambiguation category, the demangler implementations shouldn't need updated (i.e. if this were an uppercase letter, then our mangle-then-demangle checks would fail because the demangler would expect to have explicit handling). `'a'` is chosen arbitrarily, for **a**sm, but I can change it to something else if preferred.
`#[rustc_symbol_name]` only looks at top-level items, and would need a bunch of changes to be able to check the symbol for `foo::{constant}::{closure}` in the `global_asm` in this test, so for now the test just checks this compiles.
The alternative to this would be to prohibit declaration of items in the operand of a `global_asm`, which is a breaking change.
Stabilize `asm_cfg`
tracking issue: https://github.com/rust-lang/rust/issues/140364
closes https://github.com/rust-lang/rust/issues/140364
Reference PR:
- https://github.com/rust-lang/reference/pull/2063
# Request for Stabilization
## Summary
The `cfg_asm` feature allows `#[cfg(...)]` and `#[cfg_attr(...)]` on the arguments of the assembly macros, for instance:
```rust
asm!( // or global_asm! or naked_asm!
"nop",
#[cfg(target_feature = "sse2")]
"nop",
// ...
#[cfg(target_feature = "sse2")]
a = const 123, // only used on sse2
);
```
## Semantics
Templates, operands, `options` and `clobber_abi` in the assembly macros (`asm!`, `naked_asm!` and `global_asm!`) can be annotated with `#[cfg(...)]` and `#[cfg_attr(...)]`. When the condition evaluates to true, the annotated argument has no effect, and is completely ignored when expanding the assembly macro.
## Documentation
reference PR: https://github.com/rust-lang/reference/pull/2063
## Tests
- [tests/ui/asm/cfg.rs](https://github.com/rust-lang/rust/blob/master/tests/ui/asm/cfg.rs) checks that `cfg`'d arguments where the condition evaluates to false have no effect
- [tests/ui/asm/cfg-parse-error.rs](https://github.com/rust-lang/rust/blob/master/tests/ui/asm/cfg.rs) checks the parsing rules (parsing effectively assumes that the cfg conditions are all true)
## History
- https://github.com/rust-lang/rust/issues/140279
- https://github.com/rust-lang/rust/pull/140367
# Resolved questions
**how are other attributes handled**
Other attributes are parsed, but explicitly rejected.
# unresolved questions
**operand before template**
The current implementation expects at least one template string before any operands. In the example below, if the `cfg` condition evaluates to true, the assembly block is ill-formed. But even when it evaluates to `false` this block is rejected, because the parser still expects just a template (a template is parsed as an expression and then validated to ensure that it is or expands to a string literal).
Changing how this works is difficult.
```rust
// This is rejected because `a = out(reg) x` does not parse as an expresion.
asm!(
#[cfg(false)]
a = out(reg) x, //~ ERROR expected token: `,`
"",
);
```
**lint on positional arguments?**
Adding a lint to warn on the definition or use of positional arguments being `cfg`'d out was discussed in https://github.com/rust-lang/rust/issues/140279#issuecomment-2832237372 and subsequent comments. Such a lint is not currently implemented, but that may not be a blocker based on the comments there.
r? `@traviscross` (I'm assuming you'll reassign as needed)
Make deref_nullptr deny by default instead of warn
This lint was added 4 years ago in https://github.com/rust-lang/rust/pull/83948 and I cannot find any discussion on that PR or its issue about whether it should be warn or deny by default.
I think keeping this lint to warn was at one point in the past justifiable because of the old bindgen behavior of generating tests that do null pointer derefs. I've certainly heard that argument. I don't think it holds up now, so I think we should be more firm about code that is definitely UB.
We merged https://github.com/rust-lang/rust/pull/134424 which adds a runtime check for null pointer reads/writes, with very little fanfare. So now we know things like: This lint warns on 111 crates in crater, but 106 crates are encountering the runtime UB check. 65 crates hit both the lint and a runtime check. Of the 46 crates that only hit the lint, 25 look to me like machine-generated bindings, and all hits except 3a0eff4bd1/src/main.rs (L454) are trying to compute a field offset, and should use `offset_of!`.
Based on the contents of the crater runs for 1.91, I'd expect these crates to go from test-fail to build-fail as a result of this change:
```
gh/bernardjason/rust-invaders
gh/Leinnan/doppler
gh/Max-E/rust-gl-python-gtk
gh/nslebruh/rust-opengl-glfw
gh/nslebruh/rust_physics_gl_test
gh/oraoto/php-stacktrace
gh/playXE/jsrs
gh/Plecra/asm-w-ownership
gh/TateKennington/ROpenGL
gh/WillFarris/voxel-game
reg/ochre
```
Most of the crates where the lint fires already don't build for other reasons (note there are a lot of C bindings wrapper crates in the set).
v0 mangling for std on nightly
Following rust-lang/rust#89917 and rust-lang/compiler-team#938, it doesn't make sense that `std` for these channels would have legacy mangling while the user's code would use `v0`.
r? `@Kobzol`
So that when we later add support for revisions we can use the same
syntax for revisions as elsewhere.
This also prevents people from making typos for commands since
`src/tools/compiletest/src/directives/directive_names.rs` will catch such
typos now.
Note that we one FIXME for a non-trivial change for later:
```
// FIXME(148097): Change `// cdb-checksimple_closure` to `//@ cdb-check:simple_closure`
```
Rollup of 6 pull requests
Successful merges:
- rust-lang/rust#148234 (rustdoc: make mergeable crate info more usable)
- rust-lang/rust#149201 (Add suggest alternatives for Out-of-range \x escapes)
- rust-lang/rust#149208 ([rustdoc] Make more functions return `fmt::Result` and reduce number of `.unwrap()` calls)
- rust-lang/rust#149252 (miri: use `tikv-jemalloc-sys` from sysroot)
- rust-lang/rust#149255 (Use `let...else` consistently in user-facing diagnostics)
- rust-lang/rust#149275 (Fix missing double-quote in `std::env::consts::OS` values)
r? `@ghost`
`@rustbot` modify labels: rollup
Use `let...else` consistently in user-facing diagnostics
resolve: rust-lang/rust#148772
Standardize `let...else` terminology in user-facing diagnostics.
Goal: Consistently use `let...else` in all error/warning messages.
Internal technical names (`let-else`) in comments and documentation remain unchanged.
cc ``@carols10cents,`` ``@jieyouxu``
[rustdoc] Make more functions return `fmt::Result` and reduce number of `.unwrap()` calls
Following our discussion in https://github.com/rust-lang/rust/pull/149028#discussion_r2550675531, this PR makes more function return `fmt::Result`, allowing to use `?` a lot more, and also reducing number of `.unwrap()` calls.
r? `@lolbinarycat`
rustdoc: make mergeable crate info more usable
Part of https://github.com/rust-lang/rust/issues/130676
Adds documentation and a feature change aimed at making this usable without breaking backwards compat.
cc ``@EtomicBomb``
This allows LTO to work when compiling jemalloc, which should yield a
small performance boost, and makes miri's behaviour here match clippy
and rustdoc.
[Debugger Visualizers] Unify `*-gnu` and `*-msvc` enum output
Followup patch to rust-lang/rust#145218
Ports the msvc enum synthetic/summary logic to the gnu handlers so they have identical output. Also removes the "look-through-pointers" logic that caused rust-lang/rust#147450
<img width="629" height="220" alt="image" src="https://github.com/user-attachments/assets/d6ae44d5-232f-412d-b291-64ac52850c74" />
I know we don't run the test suite in CI anymore, but it's still useful locally so I updated the relevant tests.
