rust/library/std/src/sys/fs, branch 1.88.0

Rollup merge of #139343 - cberner:filelock_wouldblock, r=workingjubilee

2025-05-03T06:45:01+00:00

Change signature of File::try_lock and File::try_lock_shared These methods now return Result<(), TryLockError> instead of Result to make their use less errorprone These methods are unstable under the "file_lock" feature. The related tracking issue is https://github.com/rust-lang/rust/pull/130999 and this PR changes the signatures as discussed by libs-api: https://github.com/rust-lang/rust/issues/130994#issuecomment-2770838848

Change signature of File::try_lock and File::try_lock_shared

2025-05-02T03:39:05+00:00

These methods now return Result<(), TryLockError> instead of Result to make their use less errorprone

use generic Atomic type where possible

2025-04-26T23:18:08+00:00

in core/alloc/std only for now, and ignoring test files Co-authored-by: Pavel Grigorenko

Rollup merge of #139450 - NobodyXu:new-api/make-fifo, r=tgross35

2025-04-24T06:12:57+00:00

Impl new API `std::os::unix::fs::mkfifo` under feature `unix_fifo` Tracking issue #139324

Impl new API `std::os::unix::fs::mkfifo` under feature `unix_fifo`

2025-04-23T13:02:52+00:00

Tracking issue #139324 Signed-off-by: Jiahao XU

std: Use fstatat() on illumos

2025-04-18T19:44:19+00:00

Rollup merge of #139667 - 1c3t3a:remove-no-sanitize, r=m-ou-se

2025-04-16T22:16:21+00:00

cfi: Remove #[no_sanitize(cfi)] for extern weak functions Previously (https://github.com/rust-lang/rust/pull/115200, https://github.com/rust-lang/rust/pull/138002), we added `#[no_sanitize(cfi)]` to all code paths that call to a weakly linked function. In https://github.com/rust-lang/rust/pull/138349 we fixed the root cause for this issue, which means we can now remove the corresponding attributes. r? `@rcvalle`

Rollup merge of #139683 - ChrisDenton:windows-with-native, r=tgross35,joboet

2025-04-13T11:48:18+00:00

Use `with_native_path` for Windows Ideally, each platform should use their own native path type internally. This will, for example, allow passing a UTF-16 string directly to `std::fs::File::open` and therefore avoid the need for allocating a new null-terminated wide string. However, doing that for every function and platform all at once makes for a large PR that is way too prone to breaking. So this just does some of the Windows parts. As with the previous Unix PR (#138832) this is intended to be merely a refactoring so I've avoided anything that may require more substantial changes.

Rollup merge of #139382 - ChrisDenton:windows-bindgen-0-61, r=Mark-Simulacrum

2025-04-12T21:05:29+00:00

Update windows-bindgen to 0.61.0 This updates the automatically generate Windows API bindings. Not much changed this time: - There's now `Default` implementations for many types, which is convenient. It does however conflict with one place where we implemented a non-zeroed default (to set the length field). But that's no big problem. - The `--no-core` flag has been renamed to `--no-deps` to more accurately reflect its meaning (i.e. generate all necessary code without requiring additional dependencies). - The `--link` flag allows us to set the location of the `link!` macro. Currently we use our workspace's `windows_targets` crate but we could move it into library/std using `--link`. However, this would need to be co-ordinated with the `backtrace` crate (which is a separate crate but included in std using `#[path]`). So I've left that for another time.

Use with_native_path for Windows

2025-04-11T18:02:03+00:00

Also add a WCStr type