Rollup of 9 pull requests #150900
Merged
Rollup of 9 pull requests #150900
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The calls to `def_path_str` were outside the decorate callback in `node_span_lint` which caused an ICE when the warning was an allowed warning due to the call to `def_path_str` being executed but the warning not actually being emitted.
Signed-off-by: tison <[email protected]> Co-Authored-By: Orson Peters <[email protected]> Signed-off-by: tison <[email protected]>
- Just a call to get_position - Tested with OVMF on QEMU Signed-off-by: Ayush Singh <[email protected]>
When PR rust-lang#147572 switched WASI to use Unix-style filesystem APIs, the open_to_and_set_permissions function for WASI was implemented to call OpenOptions::new().open() without setting any access mode flags. This causes std::fs::copy to fail with the error: "must specify at least one of read, write, or append access" The fix is to explicitly set .write(true), .create(true), and .truncate(true) on the OpenOptions, matching the behavior of the non-WASI Unix implementation but without the permission handling that WASI doesn't support. Minimal reproduction: fn main() { std::fs::write("/src.txt", b"test").unwrap(); match std::fs::copy("/src.txt", "/dst.txt") { Ok(_) => println!("PASS: fs::copy works!"), Err(e) => println!("FAIL: {}", e), } } # Compile and run: rustc +nightly --target wasm32-wasip2 test.rs -o test.wasm wasmtime -S cli --dir . test.wasm # Before fix: FAIL: must specify at least one of read, write, or append access # After fix: PASS: fs::copy works! Note: The existing test library/std/src/fs/tests.rs::copy_file_ok would have caught this regression if the std test suite ran on WASI targets. Currently std tests don't compile for wasm32-wasip2 due to Unix-specific test code in library/std/src/sys/fd/unix/tests.rs. Fixes the regression introduced in nightly-2025-12-10.
Tested using OVMF on QEMU. Signed-off-by: Ayush Singh <[email protected]>
…oss35 Implement partial_sort_unstable for slice This refers to rust-lang#149046.
Fix ICE in inline always warning emission. The calls to `def_path_str` were outside the decorate callback in `node_span_lint` which caused an ICE when the warning was an allowed warning due to the call to `def_path_str` being executed but the warning not actually being emitted. r? @davidtwco
Fix for ICE: eii: fn / macro rules None in find_attr() Closes rust-lang#149981 This used to ICE: ```rust macro_rules! foo_impl {} #[eii] fn foo_impl() {} ``` `#[eii]` generates a macro (called `foo_impl`) and a default impl. So the partial expansion used to roughly look like the following: ```rust macro_rules! foo_impl {} // actually resolves here extern "Rust" { fn foo_impl(); } #[eii_extern_target(foo_impl)] macro foo_impl { () => {}; } const _: () = { #[implements_eii(foo_impl)] // assumed to name resolve to the macro v2 above fn foo_impl() {} }; ``` Now, shadowing rules for macrov2 and macrov1 are super weird! Take a look at this: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2024&gist=23f21421921360478b0ec0276711ad36 So instead of resolving to the macrov2, we resolve the macrov1 named the same thing. A regression test was added to this, and some span_delayed_bugs were added to make sure we catch this in the right places. But that didn't fix the root cause. To make sure this simply cannot happen again, I made it so that we don't even need to do a name resolution for the default. In other words, the new partial expansion looks more like: ```rust macro_rules! foo_impl {} extern "Rust" { fn foo_impl(); // resolves to here now!!! } #[eii_extern_target(foo_impl)] macro foo_impl { () => {}; } const _: () = { #[implements_eii(known_extern_target=foo_impl)] // still name resolved, but directly to the foreign function. fn foo_impl() {} }; ``` The reason this helps is that name resolution for non-macros is much more predictable. It's not possible to have two functions like that with the same name in scope. We used to key externally implementable items off of the defid of the macro, but now the unique identifier is the foreign function's defid which seems much more sane. Finally, I lied a tiny bit because the above partial expansion doesn't actually work. ```rust extern "Rust" { fn foo_impl(); // not to here } const _: () = { #[implements_eii(known_extern_target=foo_impl)] // actually resolves to this function itself fn foo_impl() {} // <--- so to here }; ``` So the last few commits change the expansion to actually be this: ```rust macro_rules! foo_impl {} extern "Rust" { fn foo_impl(); // resolves to here now!!! } #[eii_extern_target(foo_impl)] macro foo_impl { () => {}; } const _: () = { mod dflt { // necessary, otherwise `super` doesn't work use super::*; #[implements_eii(known_extern_target=super::foo_impl)] // now resolves to outside the `dflt` module, so the foreign item. fn foo_impl() {} } }; ``` I apologize to whoever needs to review this, this is very subtle and I hope this makes it clear enough 😭.
std: sys: fs: uefi: Implement File::read Tested using OVMF on QEMU. @rustbot label +O-UEFI
std: sys: fs: uefi: Implement File::tell - Just a call to get_position - Tested with OVMF on QEMU @rustbot label +O-UEFI
Fix std::fs::copy on WASI by setting proper OpenOptions flags When PR rust-lang#147572 switched WASI to use Unix-style filesystem APIs, the open_to_and_set_permissions function for WASI was implemented to call OpenOptions::new().open() without setting any access mode flags. This causes std::fs::copy to fail with the error: "must specify at least one of read, write, or append access" The fix is to explicitly set .write(true), .create(true), and .truncate(true) on the OpenOptions, matching the behavior of the non-WASI Unix implementation but without the permission handling that WASI doesn't support. Minimal reproduction: ```rs fn main() { std::fs::write("/src.txt", b"test").unwrap(); match std::fs::copy("/src.txt", "/dst.txt") { Ok(_) => println!("PASS: fs::copy works!"), Err(e) => println!("FAIL: {}", e), } } ``` # Compile and run: rustc +nightly --target wasm32-wasip2 test.rs -o test.wasm wasmtime -S cli --dir . test.wasm # Before fix: FAIL: must specify at least one of read, write, or append access # After fix: PASS: fs::copy works! Note: The existing test library/std/src/fs/tests.rs::copy_file_ok would have caught this regression if the std test suite ran on WASI targets. Currently std tests don't compile for wasm32-wasip2 due to Unix-specific test code in library/std/src/sys/fd/unix/tests.rs. Fixes the regression introduced in nightly-2025-12-10. r? @alexcrichton
Fix a trivial typo in def_id.rs s/then/than/
…, r=tgross35 Don't check `[mentions]` paths in submodules from tidy As we were reminded in [#triagebot > Mentions glob matching](https://rust-lang.zulipchat.com/#narrow/channel/224082-triagebot/topic/Mentions.20glob.20matching/with/567093226), triagebot cannot see changes in submodules. So let's reflect that in the `tidy` check to avoid accidentally adding paths inside submodules. I tested it with these entries: ```toml [mentions."src/tools/cargo"] cc = ["@ehuss"] [mentions."src/tools/cargo/"] cc = ["@ehuss"] [mentions."src/tools/cargo/*"] cc = ["@ehuss"] [mentions."src/tools/cargo/README.md"] cc = ["@ehuss"] ``` and got (as expected): ``` tidy [triagebot]: triagebot.toml [mentions.*] 'src/tools/cargo/README.md' cannot match inside a submodule tidy [triagebot]: triagebot.toml [mentions.*] contains 'src/tools/cargo/*' which doesn't match any file or directory in the repository ```
cg_llvm: add a pause to make comment less confusing
rustbot
added
A-attributes
rustbot
added
T-bootstrap
Member
Author
|
@bors r+ rollup=never p=5 |
rust-bors
bot
added
S-waiting-on-bors
Contributor
This comment has been minimized.
This comment has been minimized.
Contributor
Collaborator
|
📌 Perf builds for each rolled up PR:
previous master: 1191620b8c In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
Contributor
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 1191620 (parent) -> 2b82e05 (this PR) Test differencesShow 238 test diffsStage 1
Stage 2
Additionally, 232 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 2b82e05da4acaa446a0bec73a27fe351dd9d4ad6 --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 |
This was referenced Jan 10, 2026
Draft
Collaborator
|
Finished benchmarking commit (2b82e05): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)Results (secondary -2.1%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (secondary -0.1%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeResults (secondary 0.1%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Bootstrap: 472.536s -> 474.298s (0.37%) |
This was referenced Jan 10, 2026
Zalathar
added a commit
to Zalathar/rust
that referenced
this pull request
Jan 11, 2026
alloctests: Don't run the longer partial-sort tests under Miri These tests take hours to run in Miri, which greatly increases the duration of the `x86_64-gnu-aux` job, as observed in rust-lang#150900 (comment). - [Zulip thread in #t-infra](https://rust-lang.zulipchat.com/#narrow/channel/242791-t-infra/topic/x86_64-gnu-aux.20job.20went.20from.20~2.20to.20~3.2E5.20hours/near/567354541)
rust-timer
added a commit
that referenced
this pull request
Jan 11, 2026
Rollup merge of #150947 - partial-sort-miri, r=tgross35 alloctests: Don't run the longer partial-sort tests under Miri These tests take hours to run in Miri, which greatly increases the duration of the `x86_64-gnu-aux` job, as observed in #150900 (comment). - [Zulip thread in #t-infra](https://rust-lang.zulipchat.com/#narrow/channel/242791-t-infra/topic/x86_64-gnu-aux.20job.20went.20from.20~2.20to.20~3.2E5.20hours/near/567354541)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
10 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
[mentions]paths in submodules from tidy #150892 (Don't check[mentions]paths in submodules from tidy)r? @ghost
Create a similar rollup