std: Add performance warnings to HashMap::get_disjoint_mut
Closes#139296
The `get_disjoint_mut` in `HashMap` also performs a complexity O(n^2) check. So we need to be reminded of that as well.
b5b0655a37/src/raw/mod.rs (L1216-L1220)
Validate extension in `PathBuf::add_extension`
The extension is validated in `PathBuf::set_extension`, but not `add_extension`. Fix that. Check for both `/` and `\` path separators on Windows, even when the path is verbatim, since this is logically like `PathBuf::push` which normalizes separators (i.e., keeping the current behavior).
`PathBuf::add_extension` is tracked in #127292.
r? `@ChrisDenton`
The extension is validated in `PathBuf::set_extension`, but not
`add_extension`. Fix that. Check for both / and \ path separators on
Windows, even when the path is verbatim, since this is logically like
`PathBuf::push` which normalizes separators (i.e., keeping the current
behavior).
Clarify why SGX code specifies linkage/symbol names for certain statics
Specifying linkage/symbol name is solely to ensure a single instance between the `std` crate and its unit tests.
Also update the symbol names as items have moved around a bit. The actual name isn't that important, it just needs to be unique. But for debugging it can be useful for it to point to the right place.
Hermit: Unify `std::env::args` with Unix
The only differences between these implementations of `std::env::args` are that Unix uses relaxed ordering, but Hermit uses acquire/release, and Unix truncates `argv` at the first null pointer, but Hermit doesn't. Since Hermit aims for Unix compatibility, unify it with Unix.
The atomic orderings were established in https://github.com/rust-lang/rust/pull/74006 (cc `@euclio)` for Unix and https://github.com/rust-lang/rust/pull/100579 (cc `@joboet)` for Hermit and, before those, they used mutexes and non-atomic statics. I think the difference in orderings is simply from them being changed at different times. The commented explanation for using acquire/release for Hermit is “to broadcast writes by the OS”. I'm not experienced enough with atomics to accurately judge, but I think acquire/release is stronger than needed. Either way, they should match.
Truncating at the first null pointer seems desirable, though I don't know whether it is necessary in practice on Hermit.
cc `@mkroening` `@stlankes` for Hermit
SystemTime doc tweaks
* Change the `UNIX_EPOCH` link in the `SystemTime` docs to point to the associated constant, not the module level constant. The former seems to be the recommended way to access it, since aiui the only reason the module constant exists in the first place is that associated constants weren't stable yet at the time.
* Reword the comment in the `SystemTime` example - "an error occurred!" is a tad misleading; I feel like it implies a system error out of our control while `SystemTimeError` is more of a logic error.
I was originally just gonna do the first thing but I noticed the second and figured I may as well.
I'm also somewhat surprised that there aren't more in-depth module level docs for `std::time`; they don't even mention `SystemTime` at all. I might make another PR for that but mainly just wanted to flag it.
Move `pal::env` to `std::sys::env_consts`
Combine the `std::env::consts` platform implementations as a single file. Use the Unix file as the base, since it has 28 entries, and fold the 8 singleton platforms into it. The Unix file was roughly grouped into Linux, Apple, BSD, and everything else, roughly in alphabetical order. Alphabetically order them to make it easier to maintain and discard the Unix-specific groups to generalize it to all platforms.
I'd prefer to have no fallback implementation, as I consider it a bug; however TEEOS, Trusty, and Xous have no definitions here. Since they otherwise have `pal` abstractions, that indicates that there are several platforms without `pal` abstractions which are also missing here. To support unsupported, create a little macro to handle the fallback case and not introduce ordering between the `cfg`s like `cfg_if!`.
I've named the module `std::sys::env_consts`, because they are used in `std::env::consts` and I intend to use the name `std::sys::env` for the combination of `Args` and `Vars`.
cc `@joboet` `@ChrisDenton`
Tracked in #117276.
They were roughly grouped into Linux, Apple, BSD, and everything else,
roughly in alphabetical order. Alphabetically order them to make it
easier to maintain and discard the Unix-specific groups to generalize it
to all platforms.
sync::mpsc: prevent double free on `Drop`
This PR is fixing a regression introduced by #121646 that can lead to a double free when dropping the channel.
The details of the bug can be found in the corresponding crossbeam PR https://github.com/crossbeam-rs/crossbeam/pull/1187
The methods `Take::get_mut` and `Chain::get_mut` include comments
warning about modifying the I/O state of the underlying reader. However,
many readers (e.g. `File`) allow I/O using a shared reference (e.g.
`&File`). So, add the same caveat to the `get_ref` methods.
Fix: Map EOPNOTSUPP to ErrorKind::Unsupported on Unix
This change maps the EOPNOTSUPP errno value (95) to std::io::ErrorKind::Unsupported in the decode_error_kind function for Unix platforms. Previously, it was incorrectly mapped to ErrorKind::Uncategorized.
Fixes#139803
std/thread: Use default stack size from menuconfig for NuttX
* Update comments to clarify the usage of zero as an indication for default stack size configuration
* Adjust conditional compilation to reflect the changes in stack size handling for the NuttX platform
This change improves clarity and consistency in stack size configuration across platforms.
std: sys: process: uefi: Use NULL stdin by default
According to the docs in `Command::output`:
> By default, stdout and stderr are captured (and used to provide the
resulting output). Stdin is not inherited from the parent and any attempt by the child process to read from the stdin stream will result in the stream immediately closing.
This was being violated by UEFI which was inheriting stdin by default.
While the docs don't explicitly state that the default should be NULL, the behaviour seems like reading from NULL.
UEFI however, has a bit of a problem. The `EFI_SIMPLE_TEXT_INPUT_PROTOCOL` only provides support for reading 1 key press. This means that you either get an error, or it is assumed that the keypress was read successfully. So there is no way to have a successful read of length 0. Currently, I am returning UNSUPPORTED error when trying to read from NULL stdin. On linux however, you will get a read of length 0 for Null stdin.
One possible way to get around this is to translate one of the UEFI errors to a read 0 (Maybe unsupported?). It is also possible to have a non-standard error code, but well, not sure if we go that route.
Alternatively, if meaning of Stdio::Null is platform dependent, it should be fine to keep the current behaviour of returning an error.
cc ```@nicholasbishop``` ```@dvdhrm```
This change maps the EOPNOTSUPP errno value (95) to std::io::ErrorKind::Unsupported in the decode_error_kind function for Unix platforms. Previously, it was incorrectly mapped to ErrorKind::Uncategorized.
Fixes#139803
Also update the symbol names as items have moved around a bit. The actual
name isn't that important, it just needs to be unique. But for debugging
it can be useful for it to point to the right place.
The only differences between these implementations are that Unix uses
relaxed ordering, but Hermit uses acquire/release, and Unix truncates
`argv` at the first null pointer, but Hermit doesn't. Since Hermit aims
for Unix compatibility, unify it with Unix.
