Rollup of 8 pull requests - #160348
Conversation
Rely on specialization to allow `std` to provide optimized copy implementations.
Co-Authored-By: Clar Fon <15850505+clarfonthey@users.noreply.github.com>
…turn None always. Additionally, if any self.iter.nth() calls return a None, early return None as well. This fixes an edge case with non fused iterators to not advance the iterator beyond the first None item it observed in accordance with nth documentation saying that nth() will return None if n is greater than or equal to the length of the iterator.
… the underlying `RefCell`
… in `set_get_permissions_nofollows*`
At least under Windows 7, the `set_get_permissions_nofollows` and
`set_get_permissions_nofollows_symlink` FS tests currently fail on:
```
---- fs::tests::set_get_permissions_nofollows stdout ----
thread 'fs::tests::set_get_permissions_nofollows' (2308) panicked at library/std/src/test_helpers.rs:53:20:
called `Result::unwrap()` on an `Err` value: Os { code: 5, kind: PermissionDenied, message: "Access is denied." }
---- fs::tests::set_get_permissions_nofollows stdout end ----
---- fs::tests::set_get_permissions_nofollows_symlink stdout ----
thread 'fs::tests::set_get_permissions_nofollows_symlink' (1108) panicked at library/std/src/test_helpers.rs:53:20:
called `Result::unwrap()` on an `Err` value: Os { code: 5, kind: PermissionDenied, message: "Access is denied." }
---- fs::tests::set_get_permissions_nofollows_symlink stdout end ----
```
The panic clearly occurs in `TempDir::drop` that calls `fs::remove_dir_all`.
This is consistent with the fact that `FILE_ATTRIBUTE_READONLY` is set
on the file:
> Applications can read the file, but cannot write to it or delete it.
from [the attribute's documentation].
This therefore fixes these tests by resetting the attribute before
letting the drop guard run.
[the attribute's documentation]: https://learn.microsoft.com/en-us/windows/win32/fileio/file-attribute-constants
Signed-off-by: Paul Mabileau <paul.mabileau@harfanglab.fr>
…k if it conflicts with Inline attribute
…intenance-library-lock-file-maintenance, r=joboet Library lock file maintenance This PR contains the following updates: | Update | Change | |---|---| | lockFileMaintenance | All locks refreshed | 🔧 This Pull Request updates lock files to use the latest dependency versions. --- ### Configuration 📅 **Schedule**: (UTC) - Branch creation - Between 12:00 AM and 03:59 AM, only on Monday (`* 0-3 * * 1`) - Automerge - At any time (no schedule defined) 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 👻 **Immortal**: This PR will be recreated if closed unmerged. Get [config help](https://redirect.github.com/renovatebot/renovate/discussions) if that's undesired. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box --- This PR was generated by [Mend Renovate](https://mend.io/renovate/). View the [repository job log](https://developer.mend.io/github/rust-lang/rust). <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0NC4zLjIiLCJ1cGRhdGVkSW5WZXIiOiI0NC4zLjIiLCJ0YXJnZXRCcmFuY2giOiJtYWluIiwibGFiZWxzIjpbXX0=-->
…als, r=clarfonthey Move `std::io::copy` to `alloc::io` ACP: rust-lang/libs-team#755 Tracking issue: rust-lang#154046 Split From: rust-lang#156527 ~~Blocked On: rust-lang#158547 ## Description Moves `std::io::copy` into `alloc::io`. Blocked on rust-lang#158547. This relies on specialization to allow `std` to provide optimised copy implementations for its types where appropriate. The exact technique involves defining a new trait, `alloc::io::SpecCopy`: ```rust #[doc(hidden)] #[unstable(feature = "core_io_internals", reason = "exposed only for libstd", issue = "none")] #[rustc_specialization_trait] pub trait SpecCopy: Read { /// Attempt to copy from this reader to the provided writer using a specialized /// process. fn copy<R: Read + ?Sized, W: Write + ?Sized>( _reader: &mut R, _writer: &mut W, ) -> Result<CopyState>; } ``` Since optimised copying requires both the reader and writer to support the operation between each other, we can choose one of them to be the implementer of the copy algorithm, and delegate specialization to it. In this case, I've chosen the reader to be the provider of the specialized copy implementation arbitrarily. Note that the `SpecCopy::copy` function is generic over the reader specifically to allow wrappers like `Take<R>` to be visible to the implementation of `copy`. Because this introduces a new layer of specialization to `io::copy`, I think this PR should be benchmarked to make sure performance characteristics aren't too different. I am expecting compilation time to be slightly worse, since there's just more specialization happening, but the actual code run _should_ be the same. --- ## Notes * No AI tooling of any kind was used during the creation of this PR. * Please see rust-lang#154046 (comment) for a review order and broader context for this PR.
…attr_parsing, r=JonathanBrouwer Produce an error when `#[inline]` and `#[rust_force_inline]` are used together ### Merged RustcForceInline & Inline Attribute Parsers I've been reading [https://github.com/rust-lang/rust/issues/153101](https://github.com/rust-lang/rust/issues/153101), rust-lang#131229 and I came across with this comment in `compiler/rustc_attr_parsing/src/attributes/inline.rs`: ```rust // FIXME(jdonszelmann): merge these two parsers and error when both attributes are present here. // note: need to model better how duplicate attr errors work when not using // SingleAttributeParser which is what we have two of here. ``` Having separate `SingleAttributeParser` implementations for `#[rustc_force_inline]` and `#[inline(...)]` meant the compiler wasn't able to recognize cases where both of them were used together on the same item, for example: ```rust #![feature(rustc_attrs)] #[rustc_force_inline] #[inline] fn foo() {} fn main() {} ``` <img width="1222" height="915" alt="image" src="https://github.com/user-attachments/assets/69d4e3b0-bc21-4679-8f3d-017f9fe152fb" /> This case was previously considered allowed, which is not correct. My changes replace the distinct attribute parsers with a single unified `AttributeParser` implementation for `InlineParser`, handling both attributes together in a single pass. By consolidating the logic, the parser now tracks the state of both attributes side-by-side using an `AcceptMapping` and introduces a new session diagnostic, `InlineForceInlineConflict`, which is explicitly triggered in the `finalize` step if a user attempts to combine them. An added benefit of catching this conflict early during the parsing phase is that it prevents downstream validation passes (like `check_attr`) from triggering redundant errors on malformed or incorrectly placed attributes, which naturally cleans up and streamlines our compiler stderr output as reflected in the updated UI test baselines. **This is my very first PR on rustc**, and I am incredibly grateful to @hkalbasi, who heavily guided me through the codebase and helped make this change possible! Sincerely looking for your feedback and thoughts on this, let me know if there is something need to be changed.
…onthey Fix an edge case with `StepBy::nth` on non-fused iterators Fixes rust-lang#159965. From the `nth` documentation as pointed out by theemathas: > `nth()` will return `None` if `n` is greater than or equal to the length of the iterator. Currently, there is an edge case for non-fused iterator where it's able to return `Some` through `StepBy::nth` iterator even though the first item from the non-fused iterator returns `None` (it is logically an empty iterator). The issue came from how in the first take block it advances the underlying iterator forward using `.next()` and does not check if what it returns is a `None` value or not. This wouldn't be a problem for fused iterators because all the values that it would return after reaching the `None` point will also be `None`. However since non-fused iterators do not have to abide by continuously yielding `None` after reaching a `None`, it allows for a case, where after falling down from `first_take` block it can return `Some(_)` from a `self.iter.nth()` call in there. In the `first_take` block we should definitely check if the first item we got from `self.iter.next()` is `None` item, and return `None` if it is so.
…=petrochenkov Resolver: Introduce `CmRef` which has a speclative borrow variant for `CmRefCell` part of rust-lang#158845 We now introduce `CmRef` that is returned by `CmRefCell::borrow`, which does a normal borrow of the underlying `T` if we are in speculative resolution. We do not alter state during speculative resolution and because it will be run in parallel in the future, updating the `RefCell` borrow counters is not possible. Thus we just return `&T` that is "untracked". Also allows us to remove the `CmRefCell` wrapper around the external module resolution table. r? @petrochenkov
…_permissions_nofollows, r=clarfonthey
Fix(lib/fs/tests): Avoid permission denials when cleaning up TempDirs in `set_get_permissions_nofollows*`
At least under Windows 7, the `set_get_permissions_nofollows` and `set_get_permissions_nofollows_symlink` FS tests currently fail on:
```
---- fs::tests::set_get_permissions_nofollows stdout ----
thread 'fs::tests::set_get_permissions_nofollows' (2308) panicked at library/std/src/test_helpers.rs:53:20:
called `Result::unwrap()` on an `Err` value: Os { code: 5, kind: PermissionDenied, message: "Access is denied." }
---- fs::tests::set_get_permissions_nofollows stdout end ----
---- fs::tests::set_get_permissions_nofollows_symlink stdout ----
thread 'fs::tests::set_get_permissions_nofollows_symlink' (1108) panicked at library/std/src/test_helpers.rs:53:20:
called `Result::unwrap()` on an `Err` value: Os { code: 5, kind: PermissionDenied, message: "Access is denied." }
---- fs::tests::set_get_permissions_nofollows_symlink stdout end ----
```
The panic clearly occurs in `TempDir::drop` that calls `fs::remove_dir_all`. This is consistent with the fact that `FILE_ATTRIBUTE_READONLY` is set on the file:
> Applications can read the file, but cannot write to it or delete it.
from [the attribute's documentation].
This therefore fixes these tests by resetting the attribute before letting the drop guard run.
[the attribute's documentation]: https://learn.microsoft.com/en-us/windows/win32/fileio/file-attribute-constants
cc rust-lang#141607 @roblabla
@rustbot label T-libs A-io O-windows-7
tidy: Check `proc_macro_deps.rs` by reading it, not by including it As noted at rust-lang#159756 (comment), tidy shouldn't be including this file as an submodule. Instead it should prepare an expected version of the file, then load the actual file and compare the two. That reduces the likelihood of accidentally blessing the wrong path, while avoiding awkward out-of-package `#[path(..)]` attributes.
…d-allocation-box-cmp, r=TaKO8Ki Add regression test for unused_allocation on boxed comparison This issue is fixed by rust-lang#151886 Closes rust-lang#134186.
|
⌛ Trying commit a8e864f with merge e7941a9… To cancel the try build, run the command Workflow: https://github.com/rust-lang/rust/actions/runs/30710004146 |
Rollup of 8 pull requests try-job: dist-various-1 try-job: test-various try-job: x86_64-gnu-aux try-job: x86_64-gnu-llvm-21-3 try-job: x86_64-msvc-1 try-job: aarch64-apple try-job: x86_64-mingw-1 try-job: i686-msvc-*
This comment has been minimized.
This comment has been minimized.
|
@bors try cancel |
|
Try build cancelled. Cancelled workflows: |
|
📌 Perf builds for each rolled up PR:
previous master: b430378746 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 b430378 (parent) -> 73dc916 (this PR) Test differencesShow 38 test diffsStage 1
Stage 2
Additionally, 26 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 73dc9167f1cd099e525c9ade2e068d1907b78564 --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 |
|
Finished benchmarking commit (73dc916): comparison URL. Overall result: ❌ regressions - no action needed@rustbot label: -perf-regression Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (primary -0.6%, secondary -0.2%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (primary -0.4%, secondary 0.1%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeResults (primary 0.1%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Bootstrap: 489.711s -> 490.553s (0.17%) |
|
A job failed! Check out the build log: (web) (plain enhanced) (plain) Click to see the possible cause of the failure (guessed by this bot) |
Successful merges:
std::io::copytoalloc::io#158548 (Movestd::io::copytoalloc::io)#[inline]and#[rust_force_inline]are used together #158814 (Produce an error when#[inline]and#[rust_force_inline]are used together)StepBy::nthon non-fused iterators #160025 (Fix an edge case withStepBy::nthon non-fused iterators)CmRefwhich has a speclative borrow variant forCmRefCell#160271 (Resolver: IntroduceCmRefwhich has a speclative borrow variant forCmRefCell)set_get_permissions_nofollows*#160281 (Fix(lib/fs/tests): Avoid permission denials when cleaning up TempDirs inset_get_permissions_nofollows*)proc_macro_deps.rsby reading it, not by including it #160325 (tidy: Checkproc_macro_deps.rsby reading it, not by including it)r? @ghost
Create a similar rollup