| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Basic tests of MPMC receiver cloning
Ref: https://github.com/rust-lang/rust/issues/126840#issuecomment-2802321146
|
|
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: add Output::exit_ok
approved in ACP https://github.com/rust-lang/libs-team/issues/554
Tracking issue: https://github.com/rust-lang/rust/issues/84908
|
|
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```
|
|
Ref: https://github.com/rust-lang/rust/issues/126840#issuecomment-2802321146
|
|
approved in ACP https://github.com/rust-lang/libs-team/issues/554
|
|
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.
|
|
Stdio::MakePipe is not supported.
For Stdio::Null, return UNSUPPORTED. This is treated as read(0).
Additionally, have infinte loop on the notify function to prevent
wait_for_key from returning.
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
|
|
Allows implementing Stdio::Null for Command in a deterministic manner.
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
|
|
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.
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
|
|
* 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.
Signed-off-by: Huang Qi <huangqi3@xiaomi.com>
|
|
Move `args` into `std::sys`
Move platform definitions of `args` into `std::sys`, as part of https://github.com/rust-lang/rust/issues/117276.
cc ``@joboet``
|
|
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.
|
|
std: Fix build for NuttX targets
Fix std build for all NuttX targets. It is the single largest set of failures on <https://does-it-build.noratrieb.dev/>. Although, ESP-IDF also requires these same gates, there are other issues for those targets.
This can verified be running `x check library/std --target=` for all NuttX targets.
cc ``@no1wudi``
|
|
Rollup of 6 pull requests
Successful merges:
- #139107 (std: make `cmath` functions safe)
- #139607 (Add regression test for #127424)
- #139691 (Document that `opt-dist` requires metrics to be enabled)
- #139707 (Fix comment in bootstrap)
- #139708 (Fix name of field in doc comment)
- #139709 (bootstrap: fix typo in doc string)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
std: make `cmath` functions safe
The floating point intrinsics are more difficult, I'll probably wait until #119899 has merged before making them safe as well.
|
|
|
|
rustdoc-search: add unbox flag to Result aliases
Fixes #139665
|
|
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.
|
|
Revert "Disable `f16` on Aarch64 without `neon`"
The LLVM issue [1] was resolved and the fix was synced to rust-lang/rust in [2].
This reverts commit c51b229140c885cac757a405a328a07e90d5bca9.
[1]: https://github.com/llvm/llvm-project/issues/129394
[2]: https://github.com/rust-lang/rust/pull/138695
try-job: aarch64-gnu
try-job: aarch64-gnu-debug
try-job: armhf-gnu
try-job: dist-various-1
|
|
|
|
|
|
|
|
Fixes #139665
|
|
Also add a WCStr type
|
|
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
Signed-off-by: Petros Angelatos <petrosagg@gmail.com>
|
|
Signed-off-by: Petros Angelatos <petrosagg@gmail.com>
|
|
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.
|
|
Update `compiler-builtins` to 0.1.153
Includes the following changes:
* Avoid OOB access in `memcpy` and `memmove` [1]
* Enable intrinsics on AVR [2]
* `libm` updates to avoid using `core::arch` vector intrinsics [3]
* Re-enable `f16` on aarch64 without Neon [4]
[1]: https://github.com/rust-lang/compiler-builtins/pull/799
[2]: https://github.com/rust-lang/compiler-builtins/pull/791
[3]: https://github.com/rust-lang/compiler-builtins/pull/814
[4]: https://github.com/rust-lang/compiler-builtins/pull/809
|
|
Includes the following changes:
* Avoid OOB access in `memcpy` and `memmove` [1]
* Enable intrinsics on AVR [2]
* `libm` updates to avoid using `core::arch` vector intrinsics [3]
* Re-enable `f16` on aarch64 without Neon [4]
[1]: https://github.com/rust-lang/compiler-builtins/pull/799
[2]: https://github.com/rust-lang/compiler-builtins/pull/791
[3]: https://github.com/rust-lang/compiler-builtins/pull/814
[4]: https://github.com/rust-lang/compiler-builtins/pull/809
|
|
|
|
|
|
|
|
Bump boostrap compiler to new beta
try-job: `*msvc*`
|
|
std: improve documentation for get_mut() methods regarding forgotten guards
Fixes #139034
This PR improves the documentation for `get_mut()` methods in `Mutex`, `RefCell`, and `RwLock` to clarify their behavior when lock guards are forgotten (e.g., via std::mem::forget).
The current documentation for these methods states that a mutable borrow "statically guarantees no locks exist", which is not entirely accurate. While a mutable borrow prevents new locks from being created, it does not clear or detect previously abandoned locks through `forget()`. This can lead to counterintuitive behavior:
https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=e68cefec12dcd435daf2237c16824ed3
https://play.rust-lang.org/?version=nightly&mode=debug&edition=2024&gist=81263ad652c752afd63c903113d3082c
https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=311baa4edb3abf82a25c8d7bf21a4a52
r? libs
|
|
Try not to use verbatim paths in `Command::current_dir`
If possible, we should try not to use verbatim paths in `Command::current_dir`. It might work but it might also break code in the subprocess that assume the current directory isn't verbatim (including Windows APIs). cc ``@ehuss``
Side note: we now have a lot of ad-hoc fixes like this spread about the place. It'd be good to make a proper `WindowsPath` type that handles all this in one place. But that's a bigger job for another PR.
|
|
|
|
|
|
If possible, we should try not to use verbatim paths in Command::current_dir. It might work but it might also break code (including some Windows APIs) that assume the current directory isn't verbatim.
|
|
nest under platform-specific behavior,
factor rationale into its own section,
and tweak language.
|
|
fixes https://github.com/rust-lang/rust/issues/75942
fixes https://github.com/rust-lang/rust/issues/124201
|
|
Trusty: Implement `write_vectored` for stdio
Currently, `write` for stdout and stderr on Trusty is implemented with the semantics of `write_all`. Instead, call the underlying syscall only once in `write` and use the default implementation of `write_all` like other platforms. Also, implement `write_vectored` by adding support for `IoSlice`.
Refactor stdin to reuse the unsupported type like https://github.com/rust-lang/rust/pull/136769.
It requires #138875 to fix the build for Trusty, though they do not conflict and can merge in either order.
cc `@randomPoison`
|
|
Fix std build for all NuttX targets. It is the single largest set of
failures on <https://does-it-build.noratrieb.dev/>. Although, ESP-IDF
also requires these same gates, there are other issues for those
targets.
This can verified be running `x check library/std --target=` for all
NuttX targets.
|
|
Rename internal module from `statik` to `no_threads`
This module is named in reference to the keyword, but the term is somewhat overloaded. Rename it to more clearly describe it and avoid the misspelling.
|
|
Move `fd` into `std::sys`
Move platform definitions of `fd` into `std::sys`, as part of https://github.com/rust-lang/rust/issues/117276.
Unlike other modules directly under `std::sys`, this is only available on some platforms and I have not provided a fallback abstraction for unsupported platforms. That is similar to how `std::os::fd` is gated to only supported platforms.
Also, fix the `unsafe_op_in_unsafe_fn` lint, which was allowed for the Unix fd impl. Since macro expansions from `std::sys::pal::unix::weak` trigger this lint, fix it there too.
cc `@joboet,` `@ChrisDenton`
try-job: x86_64-gnu-aux
|
|
This module is named in reference to the keyword, but the term is
somewhat overloaded. Rename it to more clearly describe it and avoid the
misspelling.
|
|
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
|
