| Age | Commit message (Collapse) | Author | Lines |
|---|
|
PR 130999 added the file_lock feature, but doesn't included OpenBSD in the supported targets (Tier 3 platform), leading to a compilation error ("try_lock() not supported").
(cherry picked from commit 8792010768cff60d202b3608e6918be3199aeae2)
|
|
|
|
r=bjorn3,Noratrieb
Simplify library dependencies on `compiler-builtins`
The three panic-related library crates need to have access to `core`, and `compiler-builtins` needs to be in the crate graph. Rather than specifying both dependencies, switch these crates to use `rustc-std-workspace-core` which already does this.
This means there is now a single place that the `compiler-builtins` dependency needs to get configured, for everything other than `alloc` and `std`.
The second commit removes `compiler-builtins` from `std` (more details in the message).
|
|
`compiler-builtins` is already in the crate graph via `alloc`, and all
features related to `compiler-builtins` goes through `alloc`. There
isn't any reason that `std` needs this direct dependency, so remove it.
|
|
The three panic-related library crates need to have access to `core`,
and `compiler-builtins` needs to be in the crate graph. Rather than
specifying both dependencies, switch these crates to use
`rustc-std-workspace-core` which already does this.
This means there is now a single place that the `compiler-builtins`
dependency needs to get configured, for everything other than `alloc`
and `std`.
|
|
`compiler_builtins` shouldn't be called directly. Change the `PartialEq`
implementation for `DevicePathNode` to use slice equality instead, which
will call `memcmp`/`bcmp` via the intrinsic.
|
|
`std_detect`: Linux 6.16 support for RISC-V
It adds feature detection of 1 extension (new in `std_detect`).
New RISC-V Extension:
1. "Zabha"
|
|
Make `libtest::ERROR_EXIT_CODE` const public to not redefine it in rustdoc
I think it's better to make this constant public so it can be used by crates using `libtest` as dependency.
As a side-note, I will update https://github.com/rust-lang/rust/pull/143900 to make use of this constant once this is current PR is merged.
|
|
|
|
It adds feature detection of 1 extension (new in std_detect).
New RISC-V Extension:
1. "Zabha"
|
|
Implement `push_mut`
Implementation of rust-lang/rust#135974.
|
|
|
|
Rollup of 8 pull requests
Successful merges:
- rust-lang/rust#144034 (tests: Test line number in debuginfo for diverging function calls)
- rust-lang/rust#144510 (Fix Ord, Eq and Hash implementation of panic::Location)
- rust-lang/rust#144583 (Enable T-compiler backport nomination)
- rust-lang/rust#144586 (Update wasi-sdk to 27.0 in CI)
- rust-lang/rust#144605 (Resolve: cachify `ExternPreludeEntry.binding` through a `Cell`)
- rust-lang/rust#144632 (Update some tests for LLVM 21)
- rust-lang/rust#144639 (Update rustc-perf submodule)
- rust-lang/rust#144640 (Add support for the m68k architecture in 'object_architecture')
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Fix Ord, Eq and Hash implementation of panic::Location
Fixes https://github.com/rust-lang/rust/issues/144486.
Now properly compares/hashes the filename rather than the pointer to the string.
|
|
LoongArch64 LSX fast-path for `str.contains(&str)`
Benchmark results with LLVM 21 on LA664:
```
OLD:
test bench_is_contained_in ... bench: 43.63 ns/iter (+/- 0.04)
NEW:
test bench_is_contained_in ... bench: 12.81 ns/iter (+/- 0.01)
```
|
|
Faster equality compare
Add tests
Add missing files for tests
|
|
Fix typo in `DropGuard` doc
Follows-up rust-lang/rust#144236 (I happened to see the typo yesterday but didn’t think it should delay the PR’s merge so I kept quiet, sorryyyyy).
|
|
Benchmark results with LLVM 21 on LA664:
```
OLD:
test bench_is_contained_in ... bench: 43.63 ns/iter (+/- 0.04)
NEW:
test bench_is_contained_in ... bench: 12.81 ns/iter (+/- 0.01)
```
|
|
|
|
thread name in stack overflow message
Fixes rust-lang/rust#144481, which is caused by the thread name not being initialised yet when setting up the stack overflow information. Unfortunately, the stack overflow UI test did not test for the correct thread name being present, and testing this separately didn't occur to me when writing https://github.com/rust-lang/rust/pull/140628.
This PR contains the smallest possible fix I could think of: passing the thread name explicitly to the platform thread creation function. In the future I'd very much like to explore some possibilities around merging the thread packet and thread handle into one structure and using that in the platform code instead – but that's best left for another PR.
This PR also amends the stack overflow test to check for thread names, so we don't run into this again.
``@rustbot`` label +beta-nominated
|
|
Document why `Range*<&T> as RangeBounds<T>` impls are not `T: ?Sized`, and give an alternative.
`Range*<&T> as RangeBounds<T>` impls have been tried to be relaxed to `T: ?Sized` at least twice:
* https://github.com/rust-lang/rust/pull/61584
* https://github.com/rust-lang/rust/pull/64327
I also was just about to make another PR to do it again until I `./x.py test library/alloc` and rediscovered the type inference regression, then searched around and found the previous PRs. Hence this PR instead so hopefully that doesn't keep happening :stuck_out_tongue:.
These impls cannot be relaxed for two reasons:
1. Type inference regressions: See ``@SimonSapin's`` explanation from a previous PR: https://github.com/rust-lang/rust/pull/61584#issuecomment-499601046
2. It's a breaking change: `impl RangeBounds<MyUnsizedType> for std::ops::Range<&MyUnsizedType>` is allowed after the coherence rebalance ([playground link](https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=f704a6fe53bfc33e55b2fc246d895ec2)), and relaxing these impls would conflict with that downstream impl.
This PR adds doc-comments explaining that not having `T: ?Sized` is intentional[^1], and gives an explicit alternative: `(Bound<&T>, Bound<&T>)`.
Technically, the impls for the unstable new `std::range` types could be relaxed, as they are still unstable so the change would not be breaking, but having them be different in this regard seems worse (and the non-iterable `RangeTo/RangeToInclusive` range types are shared between the "new" and "old" so cannot be changed anyway), and then the type inference regression would pop up in whatever edition the new range types stabilize in.
The "see \<link\> for discussion of those issues" is intentionally left as a non-doc comment just for whoever may try to relax these impls again in the future, but if it is preferred to have the link in the docs I can add that.
Closes https://github.com/rust-lang/rust/issues/107196 (as wontfix)
CC https://github.com/rust-lang/rust/issues/64027
[^1]: "intentional" is maybe a bit of strong wording, should it instead say something like "was stabilized without it and it would be breaking to change it now"?
|
|
Implementation: `#[feature(sync_nonpoison)]`, `#[feature(nonpoison_mutex)]`
Continuation of https://github.com/rust-lang/rust/pull/134663
Tracking Issue: https://github.com/rust-lang/rust/issues/134645
This PR implements a new `sync/nonpoison` module, as well as the `nonpoison` variant of the `Mutex` lock.
There are 2 main changes here, the first is the new `nonpoison::mutex` module, and the second is the `mutex` integration tests.
For the `nonpoison::mutex` module, I did my best to align it with the current state of the `poison::mutex` module. This means that several unstable features (`mapped_lock_guards`, `lock_value_accessors`, and `mutex_data_ptr`) are also in the new `nonpoison::mutex` module, under their respective feature gates. Everything else in that file is under the correct feature gate (`#[unstable(feature = "nonpoison_mutex", issue = "134645")]`).
Everything in the `nonpoison::mutex` file is essentially identical in spirit, as we are simply removing the error case from the original `poison::mutex`.
The second big change is in the integration tests. I created a macro called that allows us to duplicate tests that are "generic" over the different mutex types, in that the poison mutex is always `unwrap`ped.
~~I think that there is an argument against doing this, as it can make the tests a bit harder to understand (and language server capabilities are weaker within macros), but I think the benefit of code deduplication here is worth it. Note that it is definitely possible to generalize this (with a few tweaks) to testing the other `nonpoison` locks when they eventually get implemented, but I'll leave that for a later discussion.~~
|
|
|
|
Adds tests for the `nonpoison::Mutex` variant by using a macro to
duplicate the existing `poison` tests.
Note that all of the tests here are adapted from the existing `poison`
tests.
|
|
This commit simply helps discern the actual changes needed to test both
poison and nonpoison locks.
|
|
Adds the equivalent `nonpoison` types to the `poison::mutex` module.
These types and implementations are gated under the `nonpoison_mutex`
feature gate.
Also blesses the ui tests that now have a name conflicts (because these
types no longer have unique names). The full path distinguishes the
different types.
Co-authored-by: Aandreba <aandreba@gmail.com>
Co-authored-by: Trevor Gross <tmgross@umich.edu>
|
|
|
|
fix `Atomic*::as_ptr` wording
r? `````@RalfJung`````
cc rust-lang/rust#144072
|
|
fixed typo chunks->as_chunks
Fixes rust-lang/rust#144555
info-:
fix typo chunks -> as_chunks
This now take us to as_chunks page when clicking on as_chunks link and not to chunks .
Thanks .
|
|
constify with_exposed_provenance
We allow `int as ptr` in const, so it only makes sense to also allow this function. Otherwise, `const fn` can't be ported to use the more explicit exposed provenance APIs.
Note that as of today, `with_exposed_provenance` in const is equivalent to `without_provenance`. However, we probably don't want to promise that: if someone does `with_exposed_provenance(MMIO_ADDR)` in const and then uses that pointer at runtime, that is something we should ensure keeps working; if someone does the same with `without_provenance` then I would consider that UB.
Tracking: https://github.com/rust-lang/rust/issues/144538
Cc `````@rust-lang/wg-const-eval````` `````@rust-lang/opsem`````
|
|
Add `core::mem::DropGuard`
## 1.0 Summary
This PR introduces a new type `core::mem::DropGuard` which wraps a value and runs a closure when the value is dropped.
```rust
use core::mem::DropGuard;
// Create a new guard around a string that will
// print its value when dropped.
let s = String::from("Chashu likes tuna");
let mut s = DropGuard::new(s, |s| println!("{s}"));
// Modify the string contained in the guard.
s.push_str("!!!");
// The guard will be dropped here, printing:
// "Chashu likes tuna!!!"
```
## 2.0 Motivation
A number of programming languages include constructs like `try..finally` or `defer` to run code as the last piece of a particular sequence, regardless of whether an error occurred. This is typically used to clean up resources, like closing files, freeing memory, or unlocking resources. In Rust we use the `Drop` trait instead, allowing us to [never having to manually close sockets](https://blog.skylight.io/rust-means-never-having-to-close-a-socket/).
While `Drop` (and RAII in general) has been working incredibly well for Rust in general, sometimes it can be a little verbose to setup. In particular when upholding invariants are local to functions, having a quick inline way to setup an `impl Drop` can be incredibly convenient. We can see this in use in the Rust stdlib, which has a number of private `DropGuard` impls used internally:
- [library/alloc/src/vec/drain.rs](https://github.com/rust-lang/rust/blob/9982d6462bedf1e793f7b2dbd655a4e57cdf67d4/library/alloc/src/vec/drain.rs#L177)
- [library/alloc/src/boxed/thin.rs](https://github.com/rust-lang/rust/blob/9982d6462bedf1e793f7b2dbd655a4e57cdf67d4/library/alloc/src/boxed/thin.rs#L362)
- [library/alloc/src/slice.rs](https://github.com/rust-lang/rust/blob/9982d6462bedf1e793f7b2dbd655a4e57cdf67d4/library/alloc/src/slice.rs#L413)
- [library/alloc/src/collections/linked_list.rs](https://github.com/rust-lang/rust/blob/9982d6462bedf1e793f7b2dbd655a4e57cdf67d4/library/alloc/src/collections/linked_list.rs#L1135)
- [library/alloc/src/collections/binary_heap/mod.rs](https://github.com/rust-lang/rust/blob/9982d6462bedf1e793f7b2dbd655a4e57cdf67d4/library/alloc/src/collections/binary_heap/mod.rs#L1816)
- [library/alloc/src/collections/btree/map.rs](https://github.com/rust-lang/rust/blob/9982d6462bedf1e793f7b2dbd655a4e57cdf67d4/library/alloc/src/collections/btree/map.rs#L1715)
- [library/alloc/src/collections/vec_deque/drain.rs](https://github.com/rust-lang/rust/blob/9982d6462bedf1e793f7b2dbd655a4e57cdf67d4/library/alloc/src/collections/vec_deque/drain.rs#L95)
- [library/alloc/src/vec/into_iter.rs](https://github.com/rust-lang/rust/blob/9982d6462bedf1e793f7b2dbd655a4e57cdf67d4/library/alloc/src/vec/into_iter.rs#L488)
- [library/std/src/os/windows/process.rs](https://github.com/rust-lang/rust/blob/9982d6462bedf1e793f7b2dbd655a4e57cdf67d4/library/std/src/os/windows/process.rs#L320)
- [tests/ui/process/win-proc-thread-attributes.rs](https://github.com/rust-lang/rust/blob/9982d6462bedf1e793f7b2dbd655a4e57cdf67d4/tests/ui/process/win-proc-thread-attributes.rs#L17)
## 3.0 Design
This PR implements what can be considered about the simplest possible design:
1. A single type `DropGuard` which takes both a generic type `T` and a closure `F`.
2. `Deref` + `DerefMut` impls to make it easy to work with the `T` in the guard.
3. An `impl Drop` on the guard which calls the closure `F` on drop.
4. An inherent `fn into_inner` which takes the type `T` out of the guard without calling the closure `F`.
Notably this design does not allow divergent behavior based on the type of drop that has occurred. The [`scopeguard` crate](https://docs.rs/scopeguard/latest/scopeguard/index.html) includes additional `on_success` and `on_onwind` variants which can be used to branch on unwind behavior instead. However [in a lot of cases](https://github.com/rust-lang/rust/issues/143612#issuecomment-3053928328) this doesn’t seem necessary, and using the arm/disarm pattern seems to provide much the same functionality:
```rust
let guard = DropGuard::new((), |s| ...); // 1. Arm the guard
other_function(); // 2. Perform operations
guard.into_inner(); // 3. Disarm the guard
```
`DropGuard` combined with this pattern seems like it should cover the vast majority of use cases for quick, inline destructors. It certainly seems like it should cover all existing uses in the stdlib, as well as all existing uses in crates like [hashbrown](https://github.com/search?q=repo%3Arust-lang%2Fhashbrown%20guard&type=code).
## 4.0 Acknowledgements
This implementation is based on the [mini-scopeguard crate](https://github.com/yoshuawuyts/mini-scopeguard) which in turn is based on the [scopeguard crate](https://docs.rs/scopeguard). The implementations only differ superficially; because of the nature of the problem there is only really one obvious way to structure the solution. And the scopeguard crate got that right!
## 5.0 Conclusion
This PR adds a new type `core::mem::DropGuard` to the stdlib which adds a small convenience helper to create inline destructors with. This would bring the majority of the functionality of the `scopeguard` crate into the stdlib, which is the [49th most downloaded crate](https://crates.io/crates?sort=downloads) on crates.io (387 million downloads).
Given the actual implementation of `DropGuard` is only around 60 lines, it seems to hit that sweet spot of low-complexity / high-impact that makes for a particularly efficient stdlib addition. Which is why I’m putting this forward for consideration; thanks!
|
|
Remove `[T]::array_chunks(_mut)`
Since libs-api is proposing as much in https://github.com/rust-lang/rust/issues/74985#issuecomment-3024465102
Closes rust-lang/rust#74985
Closes rust-lang/rust#76354
try-job: dist-various-1
try-job: dist-various-2
|
|
Weekly `cargo update`
Automation to keep dependencies in `Cargo.lock` current.
r? dep-bumps
The following is the output from `cargo update`:
```txt
compiler & tools dependencies:
Locking 3 packages to latest compatible versions
Updating ipc-channel v0.20.0 -> v0.20.1
Updating rand v0.9.1 -> v0.9.2
Updating redox_syscall v0.5.13 -> v0.5.16
note: pass `--verbose` to see 37 unchanged dependencies behind latest
library dependencies:
Locking 1 package to latest compatible version
Updating rand v0.9.1 -> v0.9.2
note: pass `--verbose` to see 2 unchanged dependencies behind latest
rustbook dependencies:
Locking 1 package to latest compatible version
Updating redox_syscall v0.5.13 -> v0.5.16
```
|
|
|
|
|
|
Fix CI for drop_guard
fix CI
fix all tidy lints
fix tidy link
add first batch of feedback from review
Add second batch of feedback from review
add third batch of feedback from review
fix failing test
Update library/core/src/mem/drop_guard.rs
Co-authored-by: Ruby Lazuli <general@patchmixolydic.com>
fix doctests
Implement changes from T-Libs-API review
And start tracking based on the tracking issue.
fix tidy lint
|
|
|
|
str: Mark unstable `round_char_boundary` feature functions as const
Mark `floor_char_boundary`, `ceil_char_boundary` const
Simplify the implementations, reducing the number of arithmetic operations
It seems unnecessary to do the lower/upper bounds calculations and extra slicing when we can jump straight to inspecting the bytes, assuming the underlying data is valid UTF-8.
Tracking issue https://github.com/rust-lang/rust/issues/93743
|
|
r=Mark-Simulacrum
Add a ratchet for moving all standard library tests to separate packages
https://github.com/rust-lang/rust/pull/136642 is the previous PR in this series. See https://github.com/rust-lang/rust/pull/135937 for the rationale of wanting to move all standard library tests to separate packages.
This also fixes std_detect testing on riscv.
|
|
update `Atomic*::from_ptr` and `Atomic*::as_ptr` docs
Since https://github.com/rust-lang/rust/pull/128778, it's allowed to perform atomic read and non-atomic read on the same atomic at the same time. Update the `Atomic*::from_ptr` and `Atomic*::as_ptr` documentation to remove expressions such as `not allowed to mix atomic and non-atomic accesses`.
see also [std::sync::atomic](https://doc.rust-lang.org/std/sync/atomic/index.html#memory-model-for-atomic-accesses)
|
|
|
|
Rollup of 6 pull requests
Successful merges:
- rust-lang/rust#143607 (Port the proc macro attributes to the new attribute parsing infrastructure)
- rust-lang/rust#144471 (Remove `compiler-builtins-{no-asm,mangled-names}`)
- rust-lang/rust#144495 (bump cargo_metadata)
- rust-lang/rust#144523 (rustdoc: save target modifiers)
- rust-lang/rust#144534 (check_static_item: explain should_check_for_sync choices)
- rust-lang/rust#144535 (miri: for ABI mismatch errors, say which argument is the problem)
Failed merges:
- rust-lang/rust#144536 (miri subtree update)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Remove `compiler-builtins-{no-asm,mangled-names}`
Remove `compiler-builtins-no-asm`
This feature used to be for when Cranelift didn't support inline
assembly, but its last uses were removed in 52933e0bd200 ("Don't disable
inline asm usage in compiler-builtins when the cranelift backend is
enabled"). and cba05a7a14b3 ("Support naked functions").
This doesn't remove the feature from the `compiler-builtins` crate, that
will be done separately in the subtree repo.
---
Remove `compiler-builtins-mangled-names`
This config was added in 207de019dc67 ("libary: Forward
compiler-builtins "asm" and "mangled-names" feature") but it does not
appear this has ever been used. The PR adding it (rust-lang/rust#78472) says that
this was exposed to help with configuration and points at the [Hermit
Cargo config], but as far as I can tell, this feature name has never
been mentioned in that repository's git history.
Thus, clean up a seemingly unneeded feature.
[Hermit Cargo config]: https://github.com/hermit-os/hermit-rs/blob/ab2b830930e6a9a98c8294997a8183feeabeda4a/.cargo/config
|
|
Don't special-case llvm.* as nounwind
Certain LLVM intrinsics, such as `llvm.wasm.throw`, can unwind. Marking them as nounwind causes us to skip cleanup of locals and optimize out `catch_unwind` under inlining or when `llvm.wasm.throw` is used directly by user code.
The motivation for forcibly marking llvm.* as nounwind is no longer present: most intrinsics are linked as `extern "C"` or other non-unwinding ABIs, so we won't codegen `invoke` for them anyway.
Closes rust-lang/rust#132416.
`@rustbot` label +T-compiler +A-panic
|
|
|
|
library/windows_targets: Fix macro expansion error in 'link' macro
A recent change altered the definition of the link! macro when the windows_raw_dylib feature is enabled, changing its syntax from pub macro {..} to pub macro($tt:tt) {..} in rust-lang/rust#143592
This change introduced a build failure with the error: "macros that expand to items must be delimited with braces or followed by a semicolon".
We add a semicolon to the line causing the issue as we also modify the non windows_raw_dylib link to make use of the link_dylib macro
|
|
If `HOME` is empty, use the fallback instead
This is a minor change in the `home_dir` api. An empty path is never (or should never be) valid so if the `HOME` environment variable is empty then let's use the fallback instead.
r? libs-api
|
|
compiler & tools dependencies:
Locking 3 packages to latest compatible versions
Updating ipc-channel v0.20.0 -> v0.20.1
Updating rand v0.9.1 -> v0.9.2
Updating redox_syscall v0.5.13 -> v0.5.16
note: pass `--verbose` to see 37 unchanged dependencies behind latest
library dependencies:
Locking 1 package to latest compatible version
Updating rand v0.9.1 -> v0.9.2
note: pass `--verbose` to see 2 unchanged dependencies behind latest
rustbook dependencies:
Locking 1 package to latest compatible version
Updating redox_syscall v0.5.13 -> v0.5.16
|
|
jplatte:matches-allow-non_exhaustive_omitted_patterns, r=Nadrieril
Disable non_exhaustive_omitted_patterns within matches! macro
Closes rust-lang/rust#117304.
I believe I can skip all of the bootstrap stuff mentioned in https://github.com/rust-lang/rust/issues/117304#issuecomment-1784414453 due to https://blog.rust-lang.org/inside-rust/2025/05/29/redesigning-the-initial-bootstrap-sequence/, right?
cc `@Jules-Bertholet`
|
|
Rollup of 9 pull requests
Successful merges:
- rust-lang/rust#140871 (Don't lint against named labels in `naked_asm!`)
- rust-lang/rust#141663 (rustdoc: add ways of collapsing all impl blocks)
- rust-lang/rust#143272 (Upgrade the `fortanix-sgx-abi` dependency)
- rust-lang/rust#143585 (`loop_match`: suggest extracting to a `const` item)
- rust-lang/rust#143698 (Fix unused_parens false positive)
- rust-lang/rust#143859 (Guarantee 8 bytes of alignment in Thread::into_raw)
- rust-lang/rust#144160 (tests: debuginfo: Work around or disable broken tests on powerpc)
- rust-lang/rust#144412 (Small cleanup: Use LocalKey<Cell> methods more)
- rust-lang/rust#144431 (Disable has_reliable_f128_math on musl targets)
r? `@ghost`
`@rustbot` modify labels: rollup
|
