- 
                Notifications
    
You must be signed in to change notification settings  - Fork 13.9k
 
Rollup of 8 pull requests #148462
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rollup of 8 pull requests #148462
Conversation
- 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 Signed-off-by: Ayush Singh <ayush@beagleboard.org>
Both gcc and llvm accept -fjump-tables as well as -fno-jump-tables. For consistency, allow rustc to accept -Zjump-tables=yes too.
Be more verbose about what this option can and cannot do.
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:100: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.
Link: rust-lang#145974 Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
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
```
    …wiser
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)._
    …, r=dtolnay Stabilize `fmt::from_fn` Resolves rust-lang#146705, pending its FCP. As discussed in that tracking issue and rust-lang#117729, this splits `fmt::from_fn` out from the `debug_closure_helpers` feature.
…s, r=wesleywiser 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#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#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#105812 by ```@ojeda``` * The stabilized CLI option is parsed as a bool: https://github.com/pmur/rust/blob/68bfda9025ccb2778e2606e12e8021b9918f40d3/compiler/rustc_session/src/options.rs#L2025-L2026 * This options adds an attribute to each llvm function via: https://github.com/pmur/rust/blob/68bfda9025ccb2778e2606e12e8021b9918f40d3/compiler/rustc_codegen_llvm/src/attributes.rs#L210-L215 * Finally, the rustc book is updated with the new option: https://github.com/pmur/rust/blob/68bfda9025ccb2778e2606e12e8021b9918f40d3/src/doc/rustc/src/codegen-options/index.md?plain=1#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#105815 as `-Zno-jump-tables`. * ```@tgross35``` created and maintained the tracking issue rust-lang#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. --- Closes rust-lang#116592
feat: add `from_fn_ptr` to `Waker` and `LocalWaker` Closes: rust-lang#146055
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```
…ieyouxu Regression test for undefined `__chkstk` on `aarch64-unknown-uefi` Adds a test for compiling a block of code with target `aarch64-unknown-uefi`. Closes rust-lang#98254
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)
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:100:5: assertion failed: saw_target_arch ``` #### Explanation Since the git checkout dir contains the word ["tests"](https://github.com/rust-lang/rust/blob/bf0ce4bc6816e3b9aaa52dc5fd47b8b5b2e0cd50/src/tools/tidy/src/pal.rs#L96), the `pal.rs` `check()` used to erroneously ignore all paths.
| 
           ☀️ Test successful - checks-actions  | 
    
| 
           📌 Perf builds for each rolled up PR: 
 previous master: 5f9dd05862 In the case of a perf regression, run the following command for each PR you suspect might be the cause:   | 
    
          What is this?This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.Comparing 5f9dd05 (parent) -> 90b6588 (this PR) Test differencesShow 23 test diffsStage 1
 Stage 2
 Additionally, 15 doctest diffs were found. These are ignored, as they are noisy. Job group index 
 Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard 90b65889799733f21ebdf59d96411aa531c5900a --output-dir test-dashboardAnd then open  Job duration changes
 How to interpret the job duration changes?Job durations can vary a lot, based on the actual runner instance  | 
    
Successful merges:
Fnclosure modifying binding #133149 (Provide more context onFnclosure modifying binding)fmt::from_fn#145915 (Stabilizefmt::from_fn)from_fn_ptrtoWakerandLocalWaker#146057 (feat: addfrom_fn_ptrtoWakerandLocalWaker)__chkstkonaarch64-unknown-uefi#148437 (Regression test for undefined__chkstkonaarch64-unknown-uefi)pal.rscheck()#148451 (tidy: Fix false positives with absolute repo paths inpal.rscheck())r? @ghost
@rustbot modify labels: rollup
Create a similar rollup