This is done by adding a global atomic variable (non-TLS) that counts how many threads are panicking. In order to check if the current thread is panicking, this variable is read and, if it is zero, no thread (including the one where `panicking` is being called) is panicking and `panicking` can return `false` immediately without needing to access TLS. If the global counter is not zero, the local counter is accessed from TLS to check if the current thread is panicking.
Add core::future::IntoFuture
This patch reintroduces the `core::future::IntoFuture` trait. However unlike earlier PRs this patch does not integrate it into the `async/.await` lowering since that lead to performance regressions. By introducing the trait separately from the integration, the integration PR can be more narrowly scoped, and people can start trying out the `IntoFuture` trait today. Thanks heaps!
cc/ @rust-lang/wg-async-foundations
## References
- Original PR adding `IntoFuture` https://github.com/rust-lang/rust/pull/65244
- Open issue to re-land `IntoFuture` (assigned to me) https://github.com/rust-lang/rust/issues/67982
- Tracking issue for `IntoFuture` https://github.com/rust-lang/rust/issues/67644
Stabilize process_set_argv0 feature for Unix
This stabilizes process_set_argv0 targeting 1.45.0. It has been
useful in practice and seems useful as-is.
The equivalent feature could be implemented for Windows, but as far as I
know nobody has. That can be done separately.
Tracking issue: #66510
This patch adds `core::future::IntoFuture`. However unlike earlier PRs this patch does not integrate it into the `async/.await` lowering. That integration should be done in a follow-up PR.
impl From<Cow> for Box, Rc, and Arc
These forward `Borrowed`/`Owned` values to existing `From` impls.
- `Box<T>` is a fundamental type, so it would be a breaking change to add a blanket impl. Therefore, `From<Cow>` is only implemented for `[T]`, `str`, `CStr`, `OsStr`, and `Path`.
- For `Rc<T>` and `Arc<T>`, `From<Cow>` is implemented for everything that implements `From` the borrowed and owned types separately.
abort_internal is safe
`sys::abort_internal` is stably exposed as a safe function. Forward that assumption "inwards" to the `sys` module by making the function itself safe, too.
This corresponds to what https://github.com/rust-lang/rust/pull/72204 did for the intrinsic. We should probably wait until that lands because some of the intrinsic calls in this PR might then need adjustments.
use the new interface to initialize conditional variables
HermitCore introduce a new interface to intialize conditional variables.
Consequently, minor changes are required to support this interface.
make abort intrinsic safe, and correct its documentation
Turns out `std::process::abort` is not the same as the intrinsic, the comment was just wrong. Quoting from the unix implementation:
```
// On Unix-like platforms, libc::abort will unregister signal handlers
// including the SIGABRT handler, preventing the abort from being blocked, and
// fclose streams, with the side effect of flushing them so libc buffered
// output will be printed. Additionally the shell will generally print a more
// understandable error message like "Abort trap" rather than "Illegal
// instruction" that intrinsics::abort would cause, as intrinsics::abort is
// implemented as an illegal instruction.
```
Updated documentation of Prefix::VerbatimDisk
PrefixComponent with Prefix::VerbatimDisk does not contain the trailing slash. The documentation here is also inconsistent with the documentation on other variants that reflect the `PrefixComponent::as_os_str()` return value.
PrefixComponent with Prefix::VerbatimDisk does not contain the trailing slash. The documentation here is also inconsistent with the documentation on other variants that reflect the `PrefixComponent::as_os_str()` return value.
This stabilizes process_set_argv0 targeting 1.45.0. It has been
useful in practice and seems useful as-is.
The equivalent feature could be implemented for Windows, but as far as I
know nobody has. That can be done separately.
Tracking issue: #66510
Allow a few warnings.
On Windows, these types were causing warnings to be emitted during the
build. These types are allowed to not have idiomatic names, so the
warning should be supressed.
On Windows, these types were causing warnings to be emitted during the
build. These types are allowed to not have idiomatic names, so the
warning should be supressed.
explain the types used in the open64 call
Fixes https://github.com/rust-lang/rust/issues/71915, where I learned about this quirk. I don't actually know what I am talking about here. ;)
Add `RefCell::take`
Add `RefCell::take` to match `Cell` and `Option`.
I also changed a couple of calls to `.replace` to `.take`.
Tracking issue is #71395.
This is my first contribution, please tell me if there's anything I could improve, thanks!
Change wording on read_vectored docs
Closes#70154
I'm happy to work with others to make the wording on this more clear. I think what I have is an improvement but may not be the final wording.
Add Read/Write::can_read/write_vectored
When working with an arbitrary reader or writer, code that uses vectored
operations may end up being slower than code that copies into a single
buffer when the underlying reader or writer doesn't actually support
vectored operations. These new methods allow you to ask the reader or
witer up front if vectored operations are efficiently supported.
Currently, you have to use some heuristics to guess by e.g. checking if
the read or write only accessed the first buffer. Hyper is one concrete
example of a library that has to do this dynamically:
0eaf304644/src/proto/h1/io.rs (L582-L594)
