Update subtree/library to 2025-05-30 #373
Merged
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
Pending fix.
```
error: cannot find a built-in macro with name `autodiff_forward`
--> library\core\src\macros\mod.rs:1542:5
|
1542 | / pub macro autodiff_forward($item:item) {
1543 | | /* compiler built-in */
1544 | | }
| |_____^
error: cannot find a built-in macro with name `autodiff_reverse`
--> library\core\src\macros\mod.rs:1549:5
|
1549 | / pub macro autodiff_reverse($item:item) {
1550 | | /* compiler built-in */
1551 | | }
| |_____^
error: could not compile `core` (lib) due to 2 previous errors
```
try_lock() and try_lock_shared() do not need to handle these per the discussion in rust-lang#140718 (comment)
This makes error propagation from try_lock() and try_lock_shared() more convenient
The implementation delegates to `<ByteStr as Display>::fmt`. Link: rust-lang/libs-team#550 Link: rust-lang#139984.
…mplementations live
…=workingjubilee Implement `normalize_lexically` Implements rust-lang#134694 This is, I think, the most straightforward implementation I could do, which will hopefully more easily allow experimentation if we decide to change the design here.
…kingjubilee Clarify WTF-8 safety docs This PR is a follow-up to PR rust-lang#140159, which clarifies ~~two things~~: - the WTF-8 safety comment [was confusing](rust-lang#140159 (comment)), either surrogate condition is actually sufficient for safety, both are not required - ~~the private `os_str::Slice` type name is easily confused with `std::slice`~~ ~~Happy to bikeshed the `OsSlice` name, other alternatives are `OsStrSlice` and `StrSlice`. Now it's got a distinct name from `std::slice`, it's easy to search and replace.~~ cc ``@thaliaarchi`` ``@workingjubilee``
…tion, r=dtolnay Specify that split_ascii_whitespace uses the same definition as is_ascii_whitespace
Attempt to improve the `std::fs::create_dir_all` docs related to atomicity The original paragraph was added in rust-lang#124520. It doesn't match the actual code logic. It says "function returns an error" if "the parent components" _(which also implies directories)_ "have been created already". The code is as follows: https://github.com/rust-lang/rust/blob/e88e85463468ce5d5ce468414eb69e3b15fa8d42/library/std/src/fs.rs#L3146 https://github.com/rust-lang/rust/blob/e88e85463468ce5d5ce468414eb69e3b15fa8d42/library/std/src/fs.rs#L3160 These lines suppress all errors if any path component is a directory. I've updated the paragraph to mirror this.
speed up charsearcher for ascii chars attempt at fixing rust-lang#82471 this implementation should be valid because ascii characters are always one byte and there are no continuation bytes that overlap with ascii characters im not completely sure that this is _always_ an improvement but it seems to be an improvement for this case and i dont think it can significantly regress any cases
intrinsics, ScalarInt: minor cleanup Taken out of rust-lang#141507 while we resolve technical disagreements in that PR. r? ``@bjorn3``
With the stage0 refactor the proc_macro version found in the sysroot will no longer always match the proc_macro version that proc-macros get compiled with by the rustc executable that uses this proc_macro. This will cause problems as soon as the ABI of the bridge gets changed to implement new features or change the way existing features work. To fix this, this commit changes rustc crates to depend directly on the local version of proc_macro which will also be used in the sysroot that rustc will build.
Add From<TryLockError> for io::Error Adds a `From` impl to make error propagation easier, as discussed in the tracking issue `TryLockError` is unstable under the "file_lock" feature. The related tracking issue is rust-lang#130994 This PR also cleanups the Windows implementation of `try_lock()` and `try_lock_shared()` as [discussed here](rust-lang#140718 (comment))
Add some track_caller info to precondition panics Currently, when you encounter a precondition check, you'll always get the caller location of the implementation of the precondition checks. But with this PR, you'll be told the location of the invalid call. Which is useful. I thought of this while looking at rust-lang#129642 (comment). The changes to `tests/ui/const*` happen because the const-eval interpreter skips `#[track_caller]` frames in its backtraces. The perf implications of this are: * Increased debug binary sizes. The caller_location implementation requires that the additional data we want to display here be stored in const allocations, which are deduplicated but not across crates. There is no impact on optimized build sizes. The panic path and the caller location data get optimized out. * The compile time hit to opt-incr-patched bitmaps happens because the patch changes the line number of some function calls with precondition checks, causing us to go from 0 dirty CGUs to 1 dirty CGU. * The other compile time hits are marginal but real, and due to doing a handful of new queries. Adding more useful data isn't completely free.
Add `Result::map_or_default` and `Option::map_or_default` Closes: rust-lang#138068 _This PR has been recreated because of the inactivity of the author (Cf. rust-lang#138068 (comment)
Rollup of 8 pull requests Successful merges: - rust-lang#140367 (add `asm_cfg`: `#[cfg(...)]` within `asm!`) - rust-lang#140894 (Make check-cfg diagnostics work in `#[doc(cfg(..))]`) - rust-lang#141252 (gvn: bail out unavoidable non-ssa locals in repeat) - rust-lang#141517 (rustdoc: use descriptive tooltip if doctest is conditionally ignored) - rust-lang#141551 (Make two transmute-related MIR lints into HIR lint) - rust-lang#141591 (ci: fix llvm test coverage) - rust-lang#141647 (Bump master `stage0` compiler) - rust-lang#141659 (Add `Result::map_or_default` and `Option::map_or_default`) r? `@ghost` `@rustbot` modify labels: rollup
Would otherwise fail on:
```
thread 'fs::tests::test_eq_windows_file_type' 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." }
```
This came from the read-only attribute set on the test file. In order to
fix this, instead of simply disabling the test, the attribute is reset
before the test's end so it may still run successfully.
Signed-off-by: Paul Mabileau <paul.mabileau@harfanglab.fr>
…manieu Add data_ptr method to Mutex and RwLock Implementation of rust-lang#140368 / rust-lang/libs-team#531. I tried to write a useful safety section about when it is safe to read or write through the returned pointers, but couldn't come up with something nice. Hoping this PR is still useful without that. I'm happy to add any doc strings other people come up with if needed before merge, of course. Unresolved questions: - Return a `LockResult` or not? - Return `*mut T` like existing APIs (`Cell::as_ptr` / `MaybeUninit::as[_mut]_ptr` / `Vec::as_ptr` / ...) or be more precise and return `NonNull<T>`?
Split `autodiff` into `autodiff_forward` and `autodiff_reverse` This PR splits `#[autodiff]` macro so `#[autodiff(df, Reverse, args)]` would become `#[autodiff_reverse(df, args)]` and `#[autodiff(df, Forward, args)]` would become `#[autodiff_forwad(df, args)]`.
…_file_type, r=ChrisDenton
Test(fs): Fix `test_eq_windows_file_type` for Windows 7
Would otherwise fail on:
```
thread 'fs::tests::test_eq_windows_file_type' 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." }
```
This came from the read-only attribute set on the test file. In order to fix this, instead of simply disabling the test, the attribute is reset before the test's end so it may still run successfully.
`@rustbot` label T-libs A-filesystem A-testsuite O-windows-7 O-windows-msvc
Path::with_extension: show that it adds an extension where one did no… …t exist I think the times I encountered this, I had to check first if files without extensions were added, since all examples only had files with existing extensions. Also, this replaced example already has a similar example below.
clean up old rintf leftovers As usual stdarch needed special treatment due to rust-lang/stdarch#1655, and apparently I forgot to clean up these leftovers here. They can be removed now.
Call out possibility of invariant result in variance markers ref rust-lang#135806 (comment)
…r=bjorn3 core: unstably expose atomic_compare_exchange so stdarch can use it Due to rust-lang/stdarch#1655, cleaning up the atomic intrinsics will be a bunch of extra work: stdarch directly calls them [here](https://github.com/rust-lang/stdarch/blob/8764244589373b8b48864c0ad11fd9233c672249/crates/core_arch/src/x86_64/cmpxchg16b.rs#L58-L74). Instead of duplicating that match, stdarch should use what we have in libcore, so let's expose that. r? `@bjorn3`
Add `rustc_diagnostic_item` to `sys::Mutex` methods For an ongoing project for adding a concurrency model checker to Miri we need to be able to intercept locking/unlocking operations on standard library mutexes. This PR adds diagnostic items to the relevant calls `lock`, `try_lock` and `unlock` for the `sys::Mutex` implementation on the targets we care about. This PR also makes the internals of `pthread::Mutex` less public, to reduce the chance of anyone locking/unlocking a mutex without going through the intercepted methods. r? ``@RalfJung``
add `CStr::display` The implementation delegates to `<ByteStr as Display>::fmt`. Link: rust-lang/libs-team#550 Link: rust-lang#139984. r? ```@BurntSushi``` cc ```@Darksonn``` ```@tgross35``` ```@ojeda``` ```@joshtriplett```
coretests: extend and simplify float tests Also de-duplicate tests by removing a ui test that duplicates the tests in core. r? `@tgross35`
Rollup of 4 pull requests Successful merges: - rust-lang#138285 (Stabilize `repr128`) - rust-lang#139994 (add `CStr::display`) - rust-lang#141571 (coretests: extend and simplify float tests) - rust-lang#141656 (CI: Add cargo tests to aarch64-apple-darwin) Failed merges: - rust-lang#141430 (remove `visit_clobber` and move `DummyAstNode` to `rustc_expand`) - rust-lang#141636 (avoid some usages of `&mut P<T>` in AST visitors) r? `@ghost` `@rustbot` modify labels: rollup
…r=onur-ozkan Do not get proc_macro from the sysroot in rustc With the stage0 refactor the proc_macro version found in the sysroot will no longer always match the proc_macro version that proc-macros get compiled with by the rustc executable that uses this proc_macro. This will cause problems as soon as the ABI of the bridge gets changed to implement new features or change the way existing features work. To fix this, this commit changes rustc crates to depend directly on the local version of proc_macro which will also be used in the sysroot that rustc will build.
tautschnig
approved these changes
May 30, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
23 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.
This is an automated PR to update the subtree/library branch to the changes from 2025-05-22 (rust-lang/rust@bf64d66) to 2025-05-30 (rust-lang/rust@1bbd62e), inclusive.
Review this PR as usual, but do not merge this PR using the GitHub web interface. Instead, once it is approved, use
git pushto literally push the changes tosubtree/librarywithout any rebase or merge.