| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
std library: use execinfo library also on NetBSD.
The execinfo library is also available on NetBSD.
|
|
fix(std): Fix undefined reference to __my_thread_exit on QNX 8.0
When cross-compiling for the x86_64/aarch64-unknown-nto-qnx800 target (QNX SDP 8.0), the build fails during the final link stage with the error:
```
error: linking with `qcc` failed: exit status: 1
...
= note: undefined reference to `__my_thread_exit'
```
- **On QNX 7.1**: The __my_thread_exit symbol is defined and exported by the main C library (libc.a/libc.so). The std backtrace code can therefore successfully take its address at compile time.
- **On QNX 8.0**: As part of a toolchain modernization, this symbol has been refactored. It is no longer present in any of the standard system libraries (.a or .so).
This patch addresses the problem at its source by conditionally compiling the problematic code.
Fixes rust-lang/rust#142726
|
|
Android has supported pipe2 since 2010, long before the current min SDK.
|
|
This commit is the start of an effort to support WASIp2 natively in the
standard library. Before this commit the `wasm32-wasip2` target behaved
exactly like `wasm32-wasip1` target by importing APIs from the core wasm
module `wasi_snapshot_preview1`. These APIs are satisfied by the
`wasm-component-ld` target by using an [adapter] which implements WASIp1
in terms of WASIp2. This adapter comes at a cost, however, in terms of
runtime indirection and instantiation cost, so ideally the adapter would
be removed entirely. The purpose of this adapter was to provide a
smoother on-ramp from WASIp1 to WASIp2 when it was originally created.
The `wasm32-wasip2` target has been around for long enough now that it's
much more established. Additionally the only thing historically blocking
using WASIp2 directly was implementation effort. Work is now underway to
migrate wasi-libc itself to using WASIp2 directly and now seems as good
a time as any to migrate the Rust standard library too.
Implementation-wise the milestones here are:
* The `wasm32-wasip2` target now also depends on the `wasi` crate at
version 0.14.* in addition to the preexisting dependency of 0.11.*.
The 0.14.* release series binds WASIp2 APIs instead of WASIp1 APIs.
* Some preexisting naming around `mod wasi` or `wasi.rs` was renamed to
`wasip1` where appropriate. For example `std::sys::pal::wasi` is now
called `std::sys::pal::wasip1`.
* More platform-specific WASI modules are now split between WASIp1 and
WASIp2. For example getting the current time, randomness, and
process arguments now use WASIp2 APIs directly instead of using WASIp1
APIs that require an adapter.
It's worth pointing out that this PR does not migrate the entire
standard library away from using WASIp1 APIs on the `wasm32-wasip2`
target. Everything related to file descriptors and filesystem APIs is
still using WASIp1. Migrating that is left for a future PR. In the
meantime the goal of this change is to lay the groundwork necessary for
migrating in the future. Eventually the goal is to drop the `wasi`
0.11.* dependency on the `wasm32-wasip2` target (the `wasm32-wasip1`
target will continue to retain this dependency).
[adapter]: https://github.com/bytecodealliance/wasmtime/blob/main/crates/wasi-preview1-component-adapter/README.md
|
|
wasm: rm static mut
More https://github.com/rust-lang/rust/issues/125035. I'm not sure this is correct, but it compiles.
|
|
Fix STD build failing for target_os = "espidf"
A regression from rust-lang/rust#142938
cc `@lolbinarycat`
cc `@ibraheemdev`
ESP-IDF (and a few other embedded Tier-3 systems) is considered `cfg(unix)`, but it does not have the `O_NOFOLLOW` flag because neither of its three supported filesystems (FATFS, LitteLF and Spiffs) has symbolic links in the first place.
What this fix does is to keep the `set_permissions_nofollow` method available and non-failing for ESP-IDF, but it behaves as if no `O_NONFOLLOW` was set. This should be fine as there is nothing to follow in the first place, as there are no symbolic links there.
EDIT: Also added the same fix for Horizon, as requested by `@Meziu.`
|
|
Move WTF-8 code from std into core and alloc
This is basically a small portion of rust-lang/rust#129411 with a smaller scope. It *does not*\* affect any public APIs; this code is still internal to the standard library. It just moves the WTF-8 code into `core` and `alloc` so it can be accessed by `no_std` crates like `backtrace`.
> \* The only public API this affects is by adding a `Debug` implementation to `std::os::windows::ffi::EncodeWide`, which was not present before. This is due to the fact that `core` requires `Debug` implementations for all types, but `std` does not (yet) require this. Even though this was ultimately changed to be a wrapper over the original type, not a re-export, I decided to keep the `Debug` implementation so it remains useful.
Like we do with ordinary strings, the tests are still located entirely in `alloc`, rather than splitting them into `core` and `alloc`.
----
Reviewer note: for ease of review, this is split into three commits:
1. Moving the original files into their new "locations"
2. Actually modifying the code to compile.
3. Removing aesthetic changes that were made so that the diff for commit 2 was readable.
You can review commits 1 and 3 to verify these claims, but commit 2 contains the majority of the changes you should care about.
----
API changes: `impl Debug for std::os::windows::ffi::EncodeWide`
|
|
Improve std::fs::read_dir docs
Call out early that the results returned can differ across calls / aren't deterministic. This was already mentioned at the bottom of examples, but I think it's worth calling out early, since this caused at least one person (me!) great confusion.
|
|
Fix wrong cache line size of riscv64
see https://go-review.googlesource.com/c/go/+/526659, All of riscv CPU using 64B for cache-line size.
|
|
Call out early that the results returned can differ across calls /
aren't deterministic. This was already mentioned at the bottom of
examples, but I think it's worth calling out early, since this caused at
least one person (me!) great confusion.
[ Added a comma to the docs, reflowed commit message - Trevor ]
|
|
Fix doc of `std::os::windows::io::BorrowedSocket::borrow_raw`
A small oversight in 0cb69dec57f I noticed while reading.
|
|
remove deprecated Error::description in impls
[libs-api permission](https://github.com/rust-lang/libs-team/issues/615#issuecomment-3074045829)
r? `@cuviper`
or `@jhpratt`
|
|
|
|
This commit adds an empty stub for the function
for QNX 8 targets. This symbol is required by the unwinder but is
not present, causing a linking failure when building with the
standard library.
Address review feedback: use whitelist for QNX versions
|
|
std/src/lib.rs: mention "search button" instead of "search bar"
r? ```@GuillaumeGomez```
|
|
Fix `LazyLock` poison panic message
Fixes the issue raised in https://github.com/rust-lang/rust/pull/144872#issuecomment-3151100248
r? ```@Amanieu```
|
|
|
|
std/sys/fd: Relax `READ_LIMIT` on Darwin
Darwin's `read`/`write` syscalls emit `EINVAL` only when `nbyte > INT_MAX`. The case `nbyte == INT_MAX` is valid, so the subtraction (`- 1`) in
```rust
const READ_LIMIT: usize = if cfg!(target_vendor = "apple") {
libc::c_int::MAX as usize - 1 // <- HERE
} else {
libc::ssize_t::MAX as usize
};
```
can be removed.
I tested that the case `nbyte == INT_MAX` is valid on various versions of macOS, including old one like Mac OS X 10.5.
The man page says:
- read() and pread() will fail if the parameter nbyte exceeds INT_MAX (link: https://keith.github.io/xcode-man-pages/read.2.html)
- write() and pwrite() will fail if the parameter nbyte exceeds INT_MAX (link: https://keith.github.io/xcode-man-pages/write.2.html)
Here are links to Darwin's code:
- [macOS 15.5] https://github.com/apple-oss-distributions/xnu/blob/e3723e1f17661b24996789d8afc084c0c3303b26/bsd/kern/sys_generic.c#L307
- [Mac OS X 10.2] https://github.com/apple/darwin-xnu/blob/d738f900846ed2d5f685e18bf85ce63b0176f61a/bsd/kern/sys_generic.c#L220
Related PR: rust-lang/rust#38622.
|
|
|
|
Signed-off-by: Connor Tsui <connor.tsui20@gmail.com>
|
|
Since `WaitTimeoutResult` is poison-agnostic, we want to use the same
type for both variants of `Condvar`.
Signed-off-by: Connor Tsui <connor.tsui20@gmail.com>
|
|
Signed-off-by: Connor Tsui <connor.tsui20@gmail.com>
|
|
Adds the equivalent `nonpoison` types to the `poison::condvar` module.
These types and implementations are gated under the `nonpoison_condvar`
feature gate.
Signed-off-by: Connor Tsui <connor.tsui20@gmail.com>
|
|
|
|
Fix some typos in LocalKey documentation
A few minor grammatical/wording changes in the `std::thread::LocalKey` documentation.
|
|
Implementation: `#[feature(nonpoison_rwlock)]`
Tracking Issue: https://github.com/rust-lang/rust/issues/134645
This PR continues the effort made in https://github.com/rust-lang/rust/pull/144022 by adding the implementation of `nonpoison::rwlock`.
Many of the changes here are similar to the changes made to implement `nonpoison::mutex`. The only real difference is that this PR includes a reorganizing of the existing `poison::rwlock` file that hopefully makes both variants more readable.
### Related PRs
- `nonpoison_condvar` implementation: https://github.com/rust-lang/rust/pull/144651
- `nonpoison_once` implementation: https://github.com/rust-lang/rust/pull/144653
|
|
Fixes an issue where if the underlying `Once` panics because it is
poisoned, the panic displays the wrong message.
Signed-off-by: Connor Tsui <connor.tsui20@gmail.com>
|
|
|
|
libstd: init(): dup() subsequent /dev/nulls instead of opening them again
This will be faster, and also it deduplicates the code so win/win
The dup() is actually infallible here. But whatever.
Before:
```
poll([{fd=0, events=0}, {fd=1, events=0}, {fd=2, events=0}], 3, 0) = 1 ([{fd=2, revents=POLLNVAL}])
openat(AT_FDCWD, "/dev/null", O_RDWR) = 2
rt_sigaction(SIGPIPE, {sa_handler=SIG_IGN, sa_mask=[PIPE], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7f5749313050}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
poll([{fd=0, events=0}, {fd=1, events=0}, {fd=2, events=0}], 3, 0) = 2 ([{fd=0, revents=POLLNVAL}, {fd=2, revents=POLLNVAL}])
openat(AT_FDCWD, "/dev/null", O_RDWR) = 0
openat(AT_FDCWD, "/dev/null", O_RDWR) = 2
rt_sigaction(SIGPIPE, {sa_handler=SIG_IGN, sa_mask=[PIPE], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7efe12006050}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
poll([{fd=0, events=0}, {fd=1, events=0}, {fd=2, events=0}], 3, 0) = 3 ([{fd=0, revents=POLLNVAL}, {fd=1, revents=POLLNVAL}, {fd=2, revents=POLLNVAL}])
openat(AT_FDCWD, "/dev/null", O_RDWR) = 0
openat(AT_FDCWD, "/dev/null", O_RDWR) = 1
openat(AT_FDCWD, "/dev/null", O_RDWR) = 2
rt_sigaction(SIGPIPE, {sa_handler=SIG_IGN, sa_mask=[PIPE], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7fc2dc7ca050}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
```
After:
```
poll([{fd=0, events=0}, {fd=1, events=0}, {fd=2, events=0}], 3, 0) = 1 ([{fd=1, revents=POLLNVAL}])
openat(AT_FDCWD, "/dev/null", O_RDWR) = 1
rt_sigaction(SIGPIPE, {sa_handler=SIG_IGN, sa_mask=[PIPE], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7f488a3fb050}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
poll([{fd=0, events=0}, {fd=1, events=0}, {fd=2, events=0}], 3, 0) = 2 ([{fd=1, revents=POLLNVAL}, {fd=2, revents=POLLNVAL}])
openat(AT_FDCWD, "/dev/null", O_RDWR) = 1
dup(1) = 2
rt_sigaction(SIGPIPE, {sa_handler=SIG_IGN, sa_mask=[PIPE], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7f1a8943c050}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
poll([{fd=0, events=0}, {fd=1, events=0}, {fd=2, events=0}], 3, 0) = 3 ([{fd=0, revents=POLLNVAL}, {fd=1, revents=POLLNVAL}, {fd=2, revents=POLLNVAL}])
openat(AT_FDCWD, "/dev/null", O_RDWR) = 0
dup(0) = 1
dup(0) = 2
rt_sigaction(SIGPIPE, {sa_handler=SIG_IGN, sa_mask=[PIPE], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7f4e3a4c7050}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
```
|
|
Add flock support for cygwin
See discussion: https://github.com/rust-lang/rust/issues/145534#issuecomment-3207265236
cc: ``@jeremyd2019``
|
|
stdlib: Replace typedef -> type alias in doc comment
'typedef' is jargon from C and C++.
Since the Rust reference uses the term [type alias](https://doc.rust-lang.org/reference/items/type-aliases.html),
this patch changes the doc comment in io/error.rs
to also use 'type alias'.
|
|
[Doc] Add links to the various collections
Add a few links to the collections mentioned in the module doc for Collections.
|
|
|
|
|
|
|
|
Clarify EOF handling for `BufRead::skip_until`
This aligns `BufRead::skip_until`'s description more with `BufRead::read_until` in terms of how it handles EOF and extends the doctest to include this behavior.
|
|
Rollup of 10 pull requests
Successful merges:
- rust-lang/rust#145538 (bufreader::Buffer::backshift: don't move the uninit bytes)
- rust-lang/rust#145542 (triagebot: Don't warn no-mentions on subtree updates)
- rust-lang/rust#145549 (Update rust maintainers in openharmony.md)
- rust-lang/rust#145550 (Avoid using `()` in `derive(From)` output.)
- rust-lang/rust#145556 (Allow stability attributes on extern crates)
- rust-lang/rust#145560 (Remove unused `PartialOrd`/`Ord` from bootstrap)
- rust-lang/rust#145568 (ignore frontmatters in `TokenStream::new`)
- rust-lang/rust#145571 (remove myself from some adhoc-groups and pings)
- rust-lang/rust#145576 (Add change tracker entry for `--timings`)
- rust-lang/rust#145578 (Add VEXos "linked files" support to `armv7a-vex-v5`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
|
|
Rollup of 15 pull requests
Successful merges:
- rust-lang/rust#145338 (actually provide the correct args to coroutine witnesses)
- rust-lang/rust#145429 (Couple of codegen_fn_attrs improvements)
- rust-lang/rust#145452 (Do not strip binaries in bootstrap everytime if they are unchanged)
- rust-lang/rust#145464 (Stabilize `const_pathbuf_osstring_new` feature)
- rust-lang/rust#145474 (Properly recover from parenthesized use-bounds (precise capturing lists) plus small cleanups)
- rust-lang/rust#145486 (Fix `unicode_data.rs` mention message)
- rust-lang/rust#145490 (Trace some basic I/O operations in bootstrap)
- rust-lang/rust#145493 (remove `should_render` in `PrintAttribute` derive)
- rust-lang/rust#145500 (Port must_use to the new target checking)
- rust-lang/rust#145505 (Simplify span caches)
- rust-lang/rust#145510 (Visit and print async_fut local for async drop.)
- rust-lang/rust#145511 (Rust build fails on OpenBSD after using file_lock feature)
- rust-lang/rust#145532 (resolve: debug for block module)
- rust-lang/rust#145533 (Reorder `lto` options from most to least optimizing)
- rust-lang/rust#145537 (Do not consider a `T: !Sized` candidate to satisfy a `T: !MetaSized` obligation.)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
A small oversight in 0cb69dec57f I noticed while reading.
|
|
r=tgross35
bufreader::Buffer::backshift: don't move the uninit bytes
previous code was perfectly sound because of MaybeUninit, but it did waste cycles on copying memory that is known to be uninitialized.
|
|
Rust build fails on OpenBSD after using file_lock feature
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").
Cc `@cberner`
Related to rust-lang/rust#130999
|
|
r=ibraheemdev
Stabilize `const_pathbuf_osstring_new` feature
This closes [tracking issue](https://github.com/rust-lang/rust/issues/141520) and stabilises `{OsString, PathBuf}::new` in const
|
|
run spellcheck as a tidy extra check in ci
This is probably how it should've been done from the start.
r? ``@Kobzol``
|
|
r=ibraheemdev
implement std::fs::set_permissions_nofollow on unix
implementation of https://github.com/rust-lang/rust/issues/141607
|
|
Remove the `From` derive macro from prelude
The new `#[derive(From)]` functionality (implemented in https://github.com/rust-lang/rust/pull/144922) caused name resolution ambiguity issues (https://github.com/rust-lang/rust/issues/145524). The reproducer looks e.g. like this:
```rust
mod foo {
pub use derive_more::From;
}
use foo::*;
#[derive(From)] // ERROR: `From` is ambiguous
struct S(u32);
```
It's pretty unfortunate that it works like this, but I guess that there's not much to be done here, and we'll have to wait for the next edition to put the `From` macro into the prelude. That will probably require https://github.com/rust-lang/rust/pull/139493 to land.
I created a new module in core (and re-exported it in std) called `from`, where I re-exported the `From` macro. I *think* that since this is a new module, it should not have the same backwards incompatibility issue.
Happy to hear suggestions about the naming - maybe it would make sense as `core::macros::from::From`? But we already had a precedent in the `core::assert_matches` module, so I just followed suit.
Fixes: https://github.com/rust-lang/rust/issues/145524
r? ``@petrochenkov``
|
