| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Attempt to improve the `std::fs::create_dir_all` docs related to atomicity
The original paragraph was added in rust-lang/rust#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.
|
|
Clarify WTF-8 safety docs
This PR is a follow-up to PR #140159, which clarifies ~~two things~~:
- the WTF-8 safety comment [was confusing](https://github.com/rust-lang/rust/pull/140159#discussion_r2082766965), 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``
|
|
Implement `normalize_lexically`
Implements #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.
|
|
|
|
Docs(lib): Fix `extract_if` docs
Various fixes to the documentation comments of the several `extract_if` collection methods available. It originally started with a small typo fix in `Vec`'s spotted when reading the 1.87 release notes, but then by looking at the others' for comparison in order to try determining what was the intended sentence, some inconsistencies were spotted. Therefore, some other changes are also proposed here to reduce these avoidable differences, going more and more nit-picky along the way. See the individual commits for more details about each change.
`@rustbot` label T-libs A-collections A-docs
|
|
|
|
|
|
|
|
|
|
rename internal panicking::try to catch_unwind
The public function is called `catch_unwind`, the intrinsic at some point got renamed to `catch_unwind` -- there's no reason to have the internal implementation of this still be called `try`, so let's rename it to match the rest.
|
|
|
|
std: sys: net: uefi: Implement TCP4 connect
- Implement TCP4 connect using EFI_TCP4_PROTOCOL.
- Tested on QEMU setup with connecting to TCP server on host.
|
|
GetUserProfileDirectoryW is now documented to always store the size
Update to match https://github.com/MicrosoftDocs/sdk-api/pull/1810
Also fix a bug in the Miri implementation while I am starting at that code...
r? ```@ChrisDenton```
Fixes #141254
|
|
|
|
chore: fix typos in comment
## Fix Typos in Comments
This PR addresses several typos in the Rust standard library's documentation comments:
- In `library/std/src/sync/mpmc/list.rs`: Corrected "attemped" to "attempted"
- In `library/std/src/sys/thread_local/guard/key.rs`: Fixed "defering" to "deferring"
- In `library/std/src/sys/thread_local/guard/key.rs`: Fixed "futher" to "further"
These changes improve documentation readability and consistency without affecting any functional code.
|
|
std: fix aliasing bug in UNIX process implementation
`CStringArray` contained both `CString`s and their pointers. Unfortunately, since `CString` uses `Box`, moving the `CString`s into the `Vec` can (under stacked borrows) invalidate the pointer to the string, meaning the resulting `Vec<*const c_char>` was, from an opsem perspective, unusable. This PR removes removes the `Vec<CString>` from `CStringArray`, instead recreating the `CString`/`CStr` from the pointers when necessary. Also,`CStringArray` is now used for the process args as well, the old implementation was suffering from the same kind of bug.
|
|
- Implement TCP4 connect using EFI_TCP4_PROTOCOL.
- Tested on QEMU setup with connecting to TCP server on host.
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
|
|
The panic machinery uses TLS, so panicking if no TLS keys are left can lead to infinite recursion (see https://github.com/rust-lang/rust/issues/140798#issuecomment-2872307377). Rather than having separate logic for the panic count and the thread name, just always abort the process if a TLS key allocation fails. This also has the benefit of aligning the key-based TLS implementation with the documentation, which does not mention that a panic could also occur because of resource exhaustion.
|
|
|
|
`CStringArray` contained both `CString`s and their pointers. Unfortunately, since `CString` uses `Box`, moving the `CString`s into the `Vec` can (under stacked borrows) invalidate the pointer to the string, meaning the resulting `Vec<*const c_char>` was, from an opsem perspective, unusable. This PR removes removes the `Vec<CString>` from `CStringArray`, instead recreating the `CString`/`CStr` from the pointers when necessary. Also,`CStringArray` is now used for the process args as well, the old implementation was suffering from the same kind of bug.
|
|
discuss deadlocks in the std::io::pipe() example
I think it's important to discuss deadlocks in examples of how to use pipes. The current example does include an explicit `drop()`, but it also implicitly relies on the fact that the `Command` object is temporary, so that it drops its copy of `pong_tx`. This sort of thing tends to trip people up when they use pipes for the first time. I might've gone overboard with the comments in this version, but I'm curious what folks think.
|
|
Update std doctests for android
This updates some doctests that fail to run on android. We will soon be supporting cross-compiled doctests, and the `arm-android` job fails to run these tests.
In summary:
- Android re-exports some traits from linux under a different path.
- Android doesn't seem to have common unix utilities like `true`, `false`, or `whoami`, so these are disabled.
|
|
|
|
rustc_on_unimplemented cleanups
Addresses some of the fixmes from https://github.com/rust-lang/rust/pull/139091 and https://github.com/rust-lang/rust/pull/140307.
- switch from `_Self` to `Self` in library
- properly validate that arguments in the `on` filter and the format strings are actually valid
See https://github.com/rust-lang/rustc-dev-guide/pull/2357 for the relevant documentation.
|
|
Rename `cfg_match!` to `cfg_select!`
[`@Nemo157` pointed out](https://github.com/rust-lang/rust/issues/115585#issuecomment-2346307605) that `cfg_match!` syntax does not actually align well with match syntax, which is a possible source of confusion. The comment points out that usage is instead more similar to ecosystem `select!` macros. Rename `cfg_match!` to `cfg_select!` to match this.
Tracking issue: https://github.com/rust-lang/rust/issues/115585
[1]: https://github.com/rust-lang/rust/issues/115585#issuecomment-2346307605
|
|
limit impls of `VaArgSafe` to just types that are actually safe
tracking issue: https://github.com/rust-lang/rust/issues/44930
Retrieving 8- or 16-bit integer arguments from a `VaList` is not safe, because such types are subject to upcasting. See https://github.com/rust-lang/rust/issues/61275#issuecomment-2193942535 for more detail.
This PR also makes the instances of `VaArgSafe` visible in the documentation, and uses a private sealed trait to make sure users cannot create additional impls of `VaArgSafe`, which would almost certainly cause UB.
r? `@workingjubilee`
|
|
8 and 16-bit integers are subject to upcasting in C, and hence are not reliably safe. users should perform their own casting and deal with the consequences
|
|
Add `std::os::unix::process::CommandExt::chroot` to safely chroot a child process
This adds a `chroot` method to the `CommandExt` extension trait for the
`Command` builder, to set a directory to chroot into. This will chroot
the child process into that directory right before calling chdir for the
`Command`'s working directory.
To avoid allowing a process to have a working directory outside of the
chroot, if the `Command` does not yet have a working directory set,
`chroot` will set its working directory to "/".
---
ACP: https://github.com/rust-lang/libs-team/issues/551
This PR currently has the tracking issue set to "none"; if the ACP is approved,
I'll file a tracking issue and update the PR.
|
|
|
|
|
|
|
|
|
|
Link `Command::current_dir`.
Co-authored-by: Amanieu d'Antras <amanieu@gmail.com>
|
|
At [1] it was pointed out that `cfg_match!` syntax does not actually
align well with match syntax, which is a possible source of confusion.
The comment points out that usage is instead more similar to ecosystem
`select!` macros. Rename `cfg_match!` to `cfg_select!` to match this.
Tracking issue: https://github.com/rust-lang/rust/issues/115585
[1]: https://github.com/rust-lang/rust/issues/115585#issuecomment-2346307605
|
|
This makes error propagation from try_lock() and try_lock_shared()
more convenient
|
|
try_lock() and try_lock_shared() do not need to handle these per the discussion in https://github.com/rust-lang/rust/pull/140718#discussion_r2076678485
|
|
use `Self` alias in self types rather than manually substituting it
Of the rougly 145 uses of `self: Ty` in the standard library, 5 of them don't use `Self` but instead choose to manually "substitute" the `impl`'s self type into the type.
This leads to weird behavior sometimes (https://github.com/rust-lang/rust/issues/140611#issuecomment-2883761300) -- **to be clear**, none of these usages actually trigger any bugs, but it's possible that they may break in the future (or at least lead to lints), so let's just "fix" them proactively.
|
|
|
|
|
|
process
This adds a `chroot` method to the `CommandExt` extension trait for the
`Command` builder, to set a directory to chroot into. This will chroot
the child process into that directory right before calling chdir for the
`Command`'s working directory.
To avoid allowing a process to have a working directory outside of the
chroot, if the `Command` does not yet have a working directory set,
`chroot` will set its working directory to "/".
|
|
When these functions were added in
https://github.com/rust-lang/rust/pull/138087
It made a relatively common pattern for emulating
these functions using an extension trait (which
internally uses `libm`) much more fragile.
If `core::f32` happened to be imported by the user
(to access a constant, say), then that import in
the module namespace would take precedence over
`f32` in the type namespace for resolving these
functions, running headfirst into the stability
attribute.
We ran into this in Color -
https://github.com/linebender/color - and chose to
release the remedial 0.3.1 and 0.2.4, to allow
downstream crates to build on `docs.rs`.
As these methods are perma-unstable, moving them
into a new module should not have any long-term
concerns, and ensures that this breakage doesn't
adversely impact anyone else.
|
|
|
|
Replace `try_reserve_exact` with `try_with_capacity` in `std::fs::read`
This change restores the previous behavior prior to #117925. That PR was made to handle OOM errors that turn into a panic with `Vec::with_capacity`. `try_reserve_exact` was used for that since there was no `try_with_capacity` method at the time. It was added later in #120504. I think it'd a better fit here.
|
|
Add `std::io::Seek` instance for `std::io::Take`
Library tracking issue [#97227](https://github.com/rust-lang/rust/issues/97227).
ACP: https://github.com/rust-lang/libs-team/issues/555
1. add a `len` field to `Take` to keep track of the original number of bytes that `Take` could read
2. add a `position()` method to return the current position of the cursor inside `Take`
3. implement `std::io::Seek` for `std::io::Take`
Closes: https://github.com/rust-lang/libs-team/issues/555
|
|
fix data race in ReentrantLock fallback for targets without 64bit atomics
See [Zulip](https://rust-lang.zulipchat.com/#narrow/channel/269128-miri/topic/reentrant.20lock.20failure.20on.20musl) for details: the address used to identify a thread might get lazily allocated inside `tls_addr()`, so if we call that *after* doing the `tls_addr.load()` it is too late to establish synchronization with prior threads that used the same address -- the `load()` thus races with the `store()` by that prior thread, and might hence see outdated values, and then the entire logic breaks down.
r? `@joboet`
|
|
|
|
GetUserProfileDirectoryW
|
|
|
|
std: stop using TLS in signal handler
TLS is not async-signal-safe, making its use in the signal handler used to detect stack overflows unsound (c.f. #133698). POSIX however lists two thread-specific identifiers that can be obtained in a signal handler: the current `pthread_t` and the address of `errno`. Since `pthread_equal` is not AS-safe, `pthread_t` should be considered opaque, so for our purposes, `&errno` is the only option. This however works nicely: we can use the address as a key into a map that stores information for each thread. This PR uses a `BTreeMap` protected by a spin lock to hold the guard page address and thread name and thus fixes #133698.
|
|
Remove #![feature(let_chains)] from library and src/librustdoc
PR https://github.com/rust-lang/rust/pull/132833 has stabilized the `let_chains` feature. This PR removes the last occurences from the library, the compiler, and librustdoc (also because #140887 missed the conditional in one of the crates as it was behind the "rustc" feature).
We keep `core` as exercise for the future as updating it is non-trivial (see PR thread).
|
