Tweak output of missing lifetime on associated type
Follow up to https://github.com/rust-lang/rust/pull/135602.
Previously we only showed the trait's assoc item if the trait was local, because we were looking for a small span only for the generics, which we don't have for foreign traits. We now use `def_span` for the item, so we at least provide some context, even if its span is too wide.
```
error[E0195]: lifetime parameters or bounds on type `IntoIter` do not match the trait declaration
--> tests/ui/lifetimes/missing-lifetime-in-assoc-type-4.rs:7:18
|
7 | type IntoIter<'a> = std::collections::btree_map::Values<'a, i32, T>;
| ^^^^ lifetimes do not match type in trait
|
::: /home/gh-estebank/rust/library/core/src/iter/traits/collect.rs:292:5
|
292 | type IntoIter: Iterator<Item = Self::Item>;
| ------------------------------------------ lifetimes in impl do not match this type in trait
```
Given an associated item that needs a named lifetime, look at the enclosing `impl` item for one. If there is none, look at the self type and the implemented trait to see if either of those has an anonimous lifetime. If so, suggest adding a named lifetime.
```
error: in the trait associated type is declared without lifetime parameters, so using a borrowed type for them requires that lifetime to come from the implemented type
--> $DIR/missing-lifetime-in-assoc-type-2.rs:5:17
|
LL | type Item = &T;
| ^ this lifetime must come from the implemented type
|
help: add a lifetime to the impl block and use it in the self type and associated type
|
LL ~ impl<'a> IntoIterator for &'a S {
LL ~ type Item = &'a T;
|
```
Move the previous long message to a note and use a shorter primary message:
```
error: missing lifetime in associated type
--> $DIR/missing-lifetime-in-assoc-type-1.rs:9:17
|
LL | impl<'a> IntoIterator for &S {
| ---- there is a named lifetime specified on the impl block you could use
...
LL | type Item = &T;
| ^ this lifetime must come from the implemented type
|
note: in the trait the associated type is declared without lifetime parameters, so using a borrowed type for them requires that lifetime to come from the implemented type
--> $SRC_DIR/core/src/iter/traits/collect.rs:LL:COL
help: consider using the lifetime from the impl block
|
LL | type Item = &'a T;
| ++
```
r? `@Nadrieril`
Rollup of 4 pull requests
Successful merges:
- rust-lang/rust#144529 (Add `#[rustc_pass_indirectly_in_non_rustic_abis]`)
- rust-lang/rust#147017 (FCW for repr(C) enums whose discriminant values do not fit into a c_int or c_uint)
- rust-lang/rust#148459 (bootstrap: Split out a separate `./x test bootstrap-py` step)
- rust-lang/rust#148468 (add logging to `fudge_inference_if_ok`)
r? `@ghost`
`@rustbot` modify labels: rollup
bootstrap: Split out a separate `./x test bootstrap-py` step
While testing changes to bootstrap, I was annoyed by the fact that `./x test bootstrap` spams a bunch of mysterious output to the console.
That output turns out to come from `bootstrap_test.py`, which runs unit tests for the Python parts of bootstrap. Those tests are (presumably) useful, but they don't add value when working on the Rust parts of bootstrap.
This PR therefore pulls them out into a separate test step that can be run with `./x test bootstrap-py`.
FCW for repr(C) enums whose discriminant values do not fit into a c_int or c_uint
Context: https://github.com/rust-lang/rust/issues/124403
The current behavior of repr(C) enums is as follows:
- The discriminant values are interpreted as const expressions of type `isize`
- We compute the smallest size that can hold all discriminant values
- The target spec contains the smallest size for repr(C) enums
- We take the larger of these two sizes
Unfortunately, this doesn't always match what C compilers do. In particular, MSVC seems to *always* give enums a size of 4 bytes, whereas the algorithm above will give enums a size of up to 8 bytes on 64bit targets. Here's an example enum affected by this:
```
// We give this size 4 on 32bit targets (with a warning since the discriminant is wrapped to fit an isize)
// and size 8 on 64bit targets.
#[repr(C)]
enum OverflowingEnum {
A = 9223372036854775807, // i64::MAX
}
// MSVC always gives this size 4 (without any warning).
// GCC always gives it size 8 (without any warning).
// Godbolt: https://godbolt.org/z/P49MaYvMd
enum overflowing_enum {
OVERFLOWING_ENUM_A = 9223372036854775807,
};
```
If we look at the C standard, then up until C20, there was no official support enums without an explicit underlying type and with discriminants that do not fit an `int`. With C23, this has changed: now enums have to grow automatically if there is an integer type that can hold all their discriminants. MSVC does not implement this part of C23.
Furthermore, Rust fundamentally cannot implement this (without major changes)! Enum discriminants work fundamentally different in Rust and C:
- In Rust, every enum has a discriminant type entirely determined by its repr flags, and then the discriminant values must be const expressions of that type. For repr(C), that type is `isize`. So from the outset we interpret 9223372036854775807 as an isize literal and never give it a chance to be stored in a bigger type. If the discriminant is given as a literal without type annotation, it gets wrapped implicitly with a warning; otherwise the user has to write `as isize` explicitly and thus trigger the wrapping. Later, we can then decide to make the *tag* that stores the discriminant smaller than the discriminant type if all discriminant values fit into a smaller type, but those values have allready all been made to fit an `isize` so nothing bigger than `isize` could ever come out of this. That makes the behavior of 32bit GCC impossible for us to match.
- In C, things flow the other way around: every discriminant value has a type determined entirely by its constant expression, and then the type for the enum is determined based on that. IOW, the expression can have *any type* a priori, different variants can even use a different type, and then the compiler is supposed to look at the resulting *values* (presumably as mathematical integers) and find a type that can hold them all. For the example above, 9223372036854775807 is a signed integer, so the compiler looks for the smallest signed type that can hold it, which is `long long`, and then uses that to compute the size of the enum (at least that's what C23 says should happen and GCC does this correctly).
Realistically I think the best we can do is to not attempt to support C23 enums, and to require repr(C) enums to satisfy the C20 requirements: all discriminants must fit into a c_int. So that's what this PR implements, by adding a FCW for enums with discriminants that do not fit into `c_int`. As a slight extension, we do *not* lint enums where all discriminants fit into a `c_uint` (i.e. `unsigned int`): while C20 does (in my reading) not allow this, and C23 does not prescribe the size of such an enum, this seems to behave consistently across compilers (giving the enum the size of an `unsigned int`). IOW, the lint fires whenever our layout algorithm would make the enum larger than an `int`, irrespective of whether we pick a signed or unsigned discriminant. This extension was added because [crater found](https://github.com/rust-lang/rust/pull/147017#issuecomment-3357077199) multiple cases of such enums across the ecosystem.
Note that it is impossible to trigger this FCW on targets where isize and c_int are the same size (i.e., the typical 32bit target): since we interpret discriminant values as isize, by the time we look at them, they have already been wrapped. However, we have an existing lint (overflowing_literals) that should notify people when this kind of wrapping occurs implicitly. Also, 64bit targets are much more common. On the other hand, even on 64bit targets it is possible to fall into the same trap by writing a literal that is so big that it does not fit into isize, gets wrapped (triggering overflowing_literals), and the wrapped value fits into c_int. Furthermore, overflowing_literals is just a lint, so if it occurs in a dependency you won't notice. (Arguably there is also a more general problem here: for literals of type `usize`/`isize`, it is fairly easy to write code that only triggers `overflowing_literals` on 32bit targets, and to never see that lint if one develops on a 64bit target.)
Specifically, the above example triggers the FCW on 64bit targets, but on 32bit targets we get this err-by-default lint instead (which will be hidden if it occurs in a dependency):
```
error: literal out of range for `isize`
--> $DIR/repr-c-big-discriminant1.rs:16:9
|
LL | A = 9223372036854775807,
| ^^^^^^^^^^^^^^^^^^^
|
= note: the literal `9223372036854775807` does not fit into the type `isize` whose range is `-2147483648..=2147483647`
= note: `#[deny(overflowing_literals)]` on by default
```
Also see the tests added by this PR.
This isn't perfect, but so far I don't think I have seen a better option. In https://github.com/rust-lang/rust/pull/146504 I tried adjusting our enum logic to make the size of the example enum above actually match what C compilers do, but that's a massive breaking change since we have to change the expected type of the discriminant expression from `isize` to `i64` or even `i128` -- so that seems like a no-go. To improve the lint we could analyze things on the HIR level and specifically catch "repr(C) enums with discriminants defined as literals that are too big", but that would have to be on top of the lint in this PR I think since we'd still want to also always check the actually evaluated value (which we can't always determined on the HIR level).
Cc `@workingjubilee` `@CAD97`
Add `#[rustc_pass_indirectly_in_non_rustic_abis]`
This PR adds an internal `#[rustc_pass_indirectly_in_non_rustic_abis]` attribute that can be applied to structs. Structs marked with this attribute will always be passed using `PassMode::Indirect { on_stack: false, .. }` when being passed by value to functions with non-Rustic calling conventions. This is needed by rust-lang/rust#141980; see that PR for further details.
cc `@joshtriplett`
Convert for each range into while loop.
```rust
fn foo() {
$0for i in 3..7 {
foo(i);
}
}
```
->
```rust
fn foo() {
let mut i = 3;
while i < 7 {
foo(i);
i += 1;
}
}
```
tidy: Fix false positives with absolute repo paths in `pal.rs` `check()`
Fixes this bug:
#### Step-by-step
1. `git clone https://github.com/rust-lang/rust.git rust-improve-tests`
2. `cd rust-improve-tests`
3. `./x test tidy`
#### Expected
No tidy errors found
#### Actual
```
thread 'pal (library)' (837175) panicked at src/tools/tidy/src/pal.rs💯5:
assertion failed: saw_target_arch
```
#### Explanation
Since the git checkout dir contains the word ["tests"](bf0ce4bc68/src/tools/tidy/src/pal.rs (L96)), the `pal.rs` `check()` used to erroneously ignore all paths.
Update books
## rust-lang/book
6 commits in af415fc6c8a6823dfb4595074f27d5a3e9e2fe49..f660f341887c8bbcd6c24fbfdf5d2a262f523965
2025-10-28 01:41:51 UTC to 2025-10-24 15:39:51 UTC
- Update to Rust 1.90 (rust-lang/book#4545)
- Update to Rust 1.89 (rust-lang/book#4544)
- Update to Rust 1.88 (rust-lang/book#4543)
- Update to Rust 1.87 (rust-lang/book#4542)
- Update to Rust 1.86 (rust-lang/book#4541)
- Remove unused subheadings (rust-lang/book#4538)
## rust-lang/edition-guide
1 commits in e2ed891f00361efc26616d82590b1c85d7a8920e..5c621253d8f2a5a4adb64a6365905db67dffe3a2
2025-10-23 14:13:01 UTC to 2025-10-23 14:13:01 UTC
- Add back the link for never_type_fallback_flowing_into_unsafe (rust-lang/edition-guide#378)
## rust-lang/reference
12 commits in 752eab01cebdd6a2d90b53087298844c251859a1..e122eefff3fef362eb7e0c08fb7ffbf5f9461905
2025-10-28 20:52:27 UTC to 2025-10-21 19:42:06 UTC
- Remove custom redirect scripts (rust-lang/reference#2065)
- Avoid specifying "last import wins" for MBEs (rust-lang/reference#2057)
- Add caveats about mutable references in consts (rust-lang/reference#2058)
- Move punctuation index to an appendix, and expand for other syntaxes (rust-lang/reference#2061)
- Use American spelling for "labeled" (rust-lang/reference#2066)
- Remove rules from names intro (rust-lang/reference#2060)
- Minor adjustments to inner/outer attribute definitions (rust-lang/reference#2059)
- Change underscore to be a keyword (rust-lang/reference#2049)
- Update `proc_macro_attribute` to use the attribute template (rust-lang/reference#1889)
- Update `proc_macro` to use the attribute template (rust-lang/reference#1887)
- Update `macro_use` to use the attribute template (rust-lang/reference#1886)
- Update `macro_export` to use the attribute template (rust-lang/reference#1885)
## rust-lang/rust-by-example
7 commits in 2c9b490d70e535cf166bf17feba59e594579843f..160e6bbca70b0c01aa4de88d19db7fc5ff8447c3
2025-11-03 12:26:45 UTC to 2025-10-22 13:19:06 UTC
- Fix typos in flow_control/match/binding (rust-lang/rust-by-example#1971)
- add clarification on overflowing_literals lint (rust-lang/rust-by-example#1970)
- Update enum_use.md (rust-lang/rust-by-example#1960)
- Remove weird extra spaces in code (rust-lang/rust-by-example#1962)
- Include a link to The Rust Reference in flow_control/match/destructuring (rust-lang/rust-by-example#1963)
- Add an example showing pattern binding when matching several values in a match arm (rust-lang/rust-by-example#1966)
- Fix typo in linked list length calculation comment (rust-lang/rust-by-example#1968)
Regression test for undefined `__chkstk` on `aarch64-unknown-uefi`
Adds a test for compiling a block of code with target `aarch64-unknown-uefi`.
Closes https://github.com/rust-lang/rust/issues/98254
library: std: sys: net: uefi: tcp: Implement write_vectored
- A working vectored write implementation for TCP4.
- Also introduces a small helper UefiBox intended to be used with heap allocated UEFI DSTs.
- Tested on OVMF
cc ```@nicholasbishop```
Stabilize -Zno-jump-tables into -Cjump-tables=bool
I propose stabilizing the -Zno-jump-tables option into -Cjump-tables=<bool>.
# `-Zno-jump-tables` stabilization report
## What is the RFC for this feature and what changes have occurred to the user-facing design since the RFC was finalized?
No RFC was created for this option. This was a narrowly scoped option introduced in rust-lang/rust#105812 to support code generation requirements of the x86-64 linux kernel, and eventually other targets as Rust For Linux grows.
The tracking is rust-lang/rust#116592.
## What behavior are we committing to that has been controversial? Summarize the major arguments pro/con.
The behavior of this flag is well defined, and mimics the existing `-fno-jump-tables` option currently available with LLVM and GCC with some caveats:
* Unlike clang or gcc, this option may be ignored by the code generation backend. Rust can support multiple code-generation backends. For stabilization, only the LLVM backend honors this option.
* The usage of this option will not guarantee a library or binary is free of jump tables. To ensure a jump-table free binary, all crates in the build graph must be compiled with this option. This includes implicitly linked crates such as std or core.
* This option only enforces the crate being compiled is free of jump tables.
* No verification is done to ensure other crates are compiled with this option. Enforcing code generation options are applied across the crate graph is out of scope for this option.
What should the flag name be?
* As introduced, this option was named `-Zno-jump-tables`. However, other major toolchains allow both positive and negative variants of this option to toggle this feature. Renaming the option to `-Cjump-tables=<bool>` makes this option consistent, and if for some reason, expandable to other arguments in the future. Notably, many LLVM targets have a configurable and different thresholds for when to lower into a jump table.
## Are there extensions to this feature that remain unstable? How do we know that we are not accidentally committing to those.
No. This option is used exclusively to gate a very specific class of optimization.
## Summarize the major parts of the implementation and provide links into the code (or to PRs)
* The original PR rust-lang/rust#105812 by ```@ojeda```
* The stabilized CLI option is parsed as a bool:
68bfda9025/compiler/rustc_session/src/options.rs (L2025-L2026)
* This options adds an attribute to each llvm function via:
68bfda9025/compiler/rustc_codegen_llvm/src/attributes.rs (L210-L215)
* Finally, the rustc book is updated with the new option:
68bfda9025/src/doc/rustc/src/codegen-options/index.md (L212-L223)
## Has a call-for-testing period been conducted? If so, what feedback was received?
No. The option has originally created is being used by Rust For Linux to build the x86-64 kernel without issue.
## What outstanding bugs in the issue tracker involve this feature? Are they stabilization-blocking?
There are no outstanding issues.
## Summarize contributors to the feature by name for recognition and assuredness that people involved in the feature agree with stabilization
* ```@ojeda``` implemented this feature in rust-lang/rust#105815 as `-Zno-jump-tables`.
* ```@tgross35``` created and maintained the tracking issue rust-lang/rust#116592, and provided feedback about the naming of the cli option.
## What FIXMEs are still in the code for that feature and why is it ok to leave them there?
There are none.
## What static checks are done that are needed to prevent undefined behavior?
This option cannot cause undefined behavior. It is a boolean option with well defined behavior in both cases.
## In what way does this feature interact with the reference/specification, and are those edits prepared?
This adds a new cli option to `rustc`. The documentation is updated, and the unstable documentation cleaned up in this PR.
## Does this feature introduce new expressions and can they produce temporaries? What are the lifetimes of those temporaries?
No.
## What other unstable features may be exposed by this feature?
None.
## What is tooling support like for this feature, w.r.t rustdoc, clippy, rust-analzyer, rustfmt, etc.?
No support is required from other rust tooling.
## Open Items
- [x] Are there objections renaming `-Zno-jump-tables` to `-Cjump-tables=<bool>`? The consensus is no.
- [x] Is it desirable to keep `-Zno-jump-tables` for a period of time? The consensus is no.
---
Closesrust-lang/rust#116592
Stabilize `fmt::from_fn`
Resolvesrust-lang/rust#146705, pending its FCP.
As discussed in that tracking issue and rust-lang/rust#117729, this splits `fmt::from_fn` out from the `debug_closure_helpers` feature.
Provide more context on `Fn` closure modifying binding
When modifying a binding from inside of an `Fn` closure, point at the binding definition and suggest using an `std::sync` type that would allow the code to compile.
```
error[E0594]: cannot assign to `counter`, as it is a captured variable in a `Fn` closure
--> f703.rs:6:9
|
4 | let mut counter = 0;
| ----------- `counter` declared here, outside the closure
5 | let x: Box<dyn Fn()> = Box::new(|| {
| -- in this closure
6 | counter += 1;
| ^^^^^^^^^^^^ cannot assign
|
= help: consider using `std::sync::atomic::AtomicI32` instead, which allows for multiple threads to access and modify the value
```
This provides more context on where the binding being modified was declared, and more importantly, guides newcomers towards `std::sync` when encountering cases like these.
When the requirement comes from an argument of a local function, we already tell the user that they might want to change from `Fn` to `FnMut`:
```
error[E0594]: cannot assign to `x`, as it is a captured variable in a `Fn` closure
--> $DIR/borrow-immutable-upvar-mutation.rs:21:27
|
LL | fn to_fn<A: std::marker::Tuple, F: Fn<A>>(f: F) -> F {
| - change this to accept `FnMut` instead of `Fn`
...
LL | let mut x = 0;
| ----- `x` declared here, outside the closure
LL | let _f = to_fn(|| x = 42);
| ----- -- ^^^^^^ cannot assign
| | |
| | in this closure
| expects `Fn` instead of `FnMut`
|
= help: consider using `std::sync::atomic::AtomicI32` instead, which allows for multiple threads to access and modify the value
```
We might want to avoid the `help` in this case.
_Inspired by a [part of Niko's keynote at RustNation UK 2024](https://youtu.be/04gTQmLETFI?si=dgJL2OJRtuShkxdD&t=600)._
Rollup of 7 pull requests
Successful merges:
- rust-lang/rust#147141 (Suggest making binding `mut` on `&mut` reborrow)
- rust-lang/rust#147945 (Port `cfg!()` macro to the new attribute parsing system )
- rust-lang/rust#147951 (Add check for `+=` typo in let chains)
- rust-lang/rust#148004 (fix: Only special case single line item attribute suggestions)
- rust-lang/rust#148264 (reflect that type and const parameter can be intermixed)
- rust-lang/rust#148363 (Fix `wasm_import_module` attribute cross-crate)
- rust-lang/rust#148447 (Tweak E0401)
r? `@ghost`
`@rustbot` modify labels: rollup
When modifying a binding from inside of an `Fn` closure, point at the binding definition and suggest using an `std::sync` type that would allow the code to compile.
```
error[E0594]: cannot assign to `counter`, as it is a captured variable in a `Fn` closure
--> f703.rs:6:9
|
4 | let mut counter = 0;
| ----------- `counter` declared here, outside the closure
5 | let x: Box<dyn Fn()> = Box::new(|| {
| -- in this closure
6 | counter += 1;
| ^^^^^^^^^^^^ cannot assign
```
Tweak E0401
More accurate span pointing at use place of outer param (at ident instead of full path).
Add note explaining why outer item params can't be used in inner item.
Use structured suggestion for what `Self` should have been.
Follow up to rust-lang/rust#148370.
Fixrust-lang/rust#37892.
Fix `wasm_import_module` attribute cross-crate
This commit fixes an accidental regression from rust-lang/rust#144678 where wasm targets would now accidentally use the wrong import module map for a symbol causing a symbol to skip mangling. This can result in compilation failures when symbols are used in cross-crate situations.
Closesrust-lang/rust#148347
fix: Only special case single line item attribute suggestions
`rustc` currently special cases suggestions to add [`#[derive(_)]\n` and other attributes](dc1feabef2/compiler/rustc_errors/src/emitter.rs (L2288C36-L2288C72)), to add more context to the suggestions.
> // The suggestion adds an entire line of code, ending on a newline, so we'll also
> // print the *following* line, to provide context of what we're advising people to
> // do. Otherwise you would only see contextless code that can be confused for
> // already existing code, despite the colors and UI elements.
> // We special case `#[derive(_)]\n` and other attribute suggestions, because those
> // are the ones where context is most useful.
This special case is a bit broad at the moment and applies to suggestions just to add an attribute, as well as suggestions that contain an attribute and other code, i.e.
```rust
#[derive(Clone)]
```
and
```rust
#[cfg(not(test))]
impl Default for NewWithCfg {
fn default() -> Self {
Self::new()
}
}
```
In the latter case, adding a line for context after the suggestion doesn't provide much benefit. Example:
This PR makes it so that this special case only applies to suggestions that just add an attribute and nothing else. This will also make `rustc`'s output match `annotate-snippets`.
Add check for `+=` typo in let chains
Fixes https://github.com/rust-lang/rust/issues/147664
it does affect only cases where variable exist in scope, because if the variable is not exist in scope, the suggestion will not make any sense
I wanted to add suggestion for case where variable does not in scope to fix `y += 1` to `let y = 1` but I guess it's too much (not too much work, but too much wild predict of what user wants)? if it's good addition in your opinion I can add this in follow up
in other things I guess impl is pretty much self-explanatory, if you see there is some possibilities to improve code or/and some _edge-cases_ that I could overlooked feel free to tell about it
ah, also about why I think this change is good and why I originally took it, so it seems to me that this is possible to make this typo (I explained this in comment a little), like, both `+` and `=` is the same button (in most of layouts) and for this reasons I didn't added something like `-=` it seems more harder to make this typo
r? diagnostics
Suggest making binding `mut` on `&mut` reborrow
When a binding needs to be mutably reborrowed multiple times, suggesting removing `&mut` will lead to follow up errors. Instead suggest both making the binding mutable and removing the reborrow.
```
error[E0596]: cannot borrow `outer` as mutable, as it is not declared as mutable
--> f14.rs:2:12
|
2 | match (&mut outer, 23) {
| ^^^^^^^^^^ cannot borrow as mutable
|
note: the binding is already a mutable borrow
--> f14.rs:1:16
|
1 | fn test(outer: &mut Option<i32>) {
| ^^^^^^^^^^^^^^^^
help: consider making the binding mutable if you need to reborrow multiple times
|
1 | fn test(mut outer: &mut Option<i32>) {
| +++
help: if there is only one mutable reborrow, remove the `&mut`
|
2 - match (&mut outer, 23) {
2 + match (outer, 23) {
|
```
Address rust-lang/rust#81059.
Add LLVM range attributes to slice length parameters
It'll take a bunch more work to do this in layout -- because of cycles in `struct Foo<'a>(&'a Foo<'a>);` -- so until we figure out how to do that well, just look for slices specifically and add the proper range for the length.
Fixes the bug:
1. git clone https://github.com/rust-lang/rust.git rust-improve-tests
2. cd rust-improve-tests
3. ./x test tidy
Expected:
No tidy errors found
Actual:
```
thread 'pal (library)' (837175) panicked at src/tools/tidy/src/pal.rs💯5:
assertion failed: saw_target_arch
```
Since the git checkout dir contains the word "tests", the `pal.rs`
`check()` used to erroneously ignore all paths.
