Remove sync::Once::call_once 'static bound
See https://internals.rust-lang.org/t/sync-once-per-instance/7918 for more context.
Suggested r is @alexcrichton, the one who added the `'static` bound back in 2014. I don't want to officially r? though, if the system would even let me. I'd rather let the system choose the appropriate member since it knows more than I do.
`git blame` history for `sync::Once::call_once`'s signature:
- [std: Second pass stabilization of sync](f3a7ec7028) (Dec 2014)
```diff
- pub fn doit<F>(&'static self, f: F) where F: FnOnce() {
+ #[stable]
+ pub fn call_once<F>(&'static self, f: F) where F: FnOnce() {
```
- [libstd: use unboxed closures](cdbb3ca9b7) (Dec 2014)
```diff
- pub fn doit(&'static self, f: ||) {
+ pub fn doit<F>(&'static self, f: F) where F: FnOnce() {
```
- [std: Rewrite the `sync` module](71d4e77db8) (Nov 2014)
```diff
- pub fn doit(&self, f: ||) {
+ pub fn doit(&'static self, f: ||) {
```
> ```text
> The second layer is the layer provided by `std::sync` which is intended to be
> the thinnest possible layer on top of `sys_common` which is entirely safe to
> use. There are a few concerns which need to be addressed when making these
> system primitives safe:
>
> * Once used, the OS primitives can never be **moved**. This means that they
> essentially need to have a stable address. The static primitives use
> `&'static self` to enforce this, and the non-static primitives all use a
> `Box` to provide this guarantee.
> ```
The author of this diff is @alexcrichton. `sync::Once` now contains only a pointer to (privately hidden) `Waiter`s, which are all stack-allocated. The `'static` bound to `sync::Once` is thus unnecessary to guarantee that any OS primitives are non-relocatable.
As the `'static` bound is not required for `sync::Once`'s operation, removing it is strictly more useful. As an example, it allows attaching a one-time operation to instances rather than only to global singletons.
Unix sockets on redox
This is done using the ipcd daemon. It's not exactly like unix sockets because there is not actually a physical file for the path, but it's close enough for a basic implementation :)
This allows mio-uds and tokio-uds to work with a few modifications as well, which is exciting!
- [std: Rewrite the `sync` module71d4e77db8) (Nov 2014)
```diff
- pub fn doit(&self, f: ||) {
+ pub fn doit(&'static self, f: ||) {
```
> ```text
> The second layer is the layer provided by `std::sync` which is intended to be
> the thinnest possible layer on top of `sys_common` which is entirely safe to
> use. There are a few concerns which need to be addressed when making these
> system primitives safe:
>
> * Once used, the OS primitives can never be **moved**. This means that they
> essentially need to have a stable address. The static primitives use
> `&'static self` to enforce this, and the non-static primitives all use a
> `Box` to provide this guarantee.
> ```
The author of this diff is @alexcrichton. `sync::Once` contains only a pointer to (privately hidden) `Waiter`s, which are all stack-allocated. The `'static` bound to `sync::Once` is thus unnecessary to guarantee that any OS primitives are non-relocatable.
See https://internals.rust-lang.org/t/sync-once-per-instance/7918 for more context.
This to-be-stable attribute is equivalent to `#[lang = "oom"]`.
It is required when using the alloc crate without the std crate.
It is called by `handle_alloc_error`, which is in turned called
by "infallible" allocations APIs such as `Vec::push`.
This turned out to be important on Windows.
Calling `handle_alloc_error(Layout:🆕:<[u8; 42]>())` caused:
```
Exception thrown at 0x00007FF7C70DC399 in a.exe: 0xC0000005:
Access violation reading location 0x000000000000002A.
```
0x2A equals 42, so it looks like the `Layout::size` field of type `usize`
was interpreted as a pointer to read from.
Add the `alloc::prelude` module
It contains the re-exports that are in `std::prelude::v1` but not in `core::prelude::v1`.
Calling it prelude is somewhat of a misnomer since (unlike those modules in `std` or `core`) its contents are never implicitly imported in modules. Rather it is intended to be used with an explicit glob import like `use alloc::prelude::*;`. However there is precedent for the same misnomer with `std::io::prelude`, for example.
This new module is unstable with the same feature name as the `alloc` care. They are proposed for stabilization together in RFC https://github.com/rust-lang/rfcs/pull/2480.
Deprecate `std::env::home_dir` and fix incorrect documentation
Compare `std::env::home_dir`s claim:
> Returns the value of the 'HOME' environment variable if it is set and not equal to the empty string.
... with its actual behavior:
```
std::env::set_var("HOME", "");
println!("{:?}", std::env::var_os("HOME")); // Some("")
println!("{:?}", std::env::home_dir()); // Some("")
```
The implementation is incorrect in two cases:
- `$HOME` is set, but empty.
- An entry for the user exists in `/etc/passwd`, but it's `pw_dir` is empty.
In both cases Rust considers an empty string to be a valid home directory. This contradicts the documentation, and is wrong in general.
Haiku: several smaller fixes to build and run rust on Haiku
This PR combines three small patches that help Rust build and run on the Haiku platform. These patches do not intend to impact other platforms.
Add read_exact_at and write_all_at methods to FileExt on unix
This PR adds `FileExt::read_exact_at()` and `FileExt::write_all_at()`, which are to `read_at()` and `write_at()` as `read_exact()` and `write_all()` are to `read()` and `write()`. This allows the user to not have to deal with `ErrorKind::Interrupted` and calling the functions in a loop.
I was unsure as to how to mark these new methods so I marked them `unstable`, please let me know if I should have done it differently.
I asked in Discord and was told that as this change is small it does not require an RFC.
Implement always-fallible TryFrom for usize/isize conversions that are infallible on some platforms
This reverts commit 837d6c7023 "Remove TryFrom impls that might become conditionally-infallible with a portability lint".
This fixes#49415 by adding (restoring) missing `TryFrom` impls for integer conversions to or from `usize` or `isize`, by making them always fallible at the type system level (that is, with `Error=TryFromIntError`) even though they happen to be infallible on some platforms (for some values of `size_of::<usize>()`).
They had been removed to allow the possibility to conditionally having some of them be infallible `From` impls instead, depending on the platforms, and have the [portability lint](https://github.com/rust-lang/rfcs/pull/1868) warn when they are used in code that is not already opting into non-portability. For example `#[allow(some_lint)] usize::from(x: u64)` would be valid on code that only targets 64-bit platforms.
This PR gives up on this possiblity for two reasons:
* Based on discussion with @aturon, it seems that the portability lint is not happening any time soon. It’s better to have the conversions be available *at all* than keep blocking them for so long. Portability-lint-gated platform-specific APIs can always be added separately later.
* For code that is fine with fallibility, the alternative would force it to opt into "non-portability" even though there would be no real portability issue.
Fix some doc links
The futures crate CI always fails because of these intra doc links. I hope that this will fix this issue.
r? @steveklabnik
@cramertj
Edit: I added @steveklabnik as reviewer because this PR also adjusts a link in `src/libstd/error.rs`
Implement PartialEq between &str and OsString
This fixes#49854.
It allows equality comparison between `OsString` values and `str` references, such as `os_string == "something"`.
Add a fallback for stacktrace printing for older Windows versions.
Some time ago we switched stack inspection functions of dbghelp.dll to their newer alternatives that also capture inlined context.
Unfortunately, said new alternatives are not present in older dbghelp.dll versions.
In particular Windows 7 at the time of writing has dbghelp.dll version 6.1.7601 from 2010, that lacks StackWalkEx and friends.
Tested on my Windows 7 - both msvc and gnu versions produce a readable stacktrace.
Fixes#50138
park/park_timeout: prohibit spurious wakeups in next park
<pre><code>
// The implementation currently uses the trivial strategy of a Mutex+Condvar
// with wakeup flag, which does not actually allow spurious wakeups.
</pre></code>
Because does not actually allow spurious wakeups.
so we have let thread.inner.cvar.wait(m) in the loop to prohibit spurious wakeups.
but if notified after we locked, this notification doesn't be consumed, it return, the next park will consume this notification...this is also 'spurious wakeup' case, 'one unpark() wakeups two park()'.
We should improve this situation：
`thread.inner.state.store(EMPTY, SeqCst);`
PR #47252 switched stack inspection functions of dbghelp.dll
to their newer alternatives that also capture inlined context.
Unfortunately, said new alternatives are not present in older
dbghelp.dll versions.
In particular Windows 7 at the time of writing has dbghelp.dll
version 6.1.7601 from 2010, that lacks StackWalkEx and friends.
Fixes#50138
Fix the error reference for LocalKey::try_with
There's no such thing as `ThreadLocalError` and the method obviously returns `AccessError`, so adjusting (probably only outdated docs).
Document round-off error in `.mod_euc()`-method, see issue #50179
Due to a round-off error the method `.mod_euc()` of both `f32` and `f64` can produce mathematical invalid outputs. If `self` in magnitude is much small than the modulus `rhs` and negative, `self + rhs` in the first branch cannot be represented in the given precision and results into `rhs`. In the mathematical strict sense, this breaks the definition. But given the limitation of floating point arithmetic it can be thought of the closest representable value to the true result, although it is not strictly in the domain `[0.0, rhs)` of the function. It is rather the left side asymptotical limit. It would be desirable that it produces the mathematical more sound approximation of `0.0`, the right side asymptotical limit. But this breaks the property, that `self == self.div_euc(rhs) * rhs + a.mod_euc(rhs)`.
The discussion in issue #50179 did not find an satisfying conclusion to which property is deemed more important. But at least we can document the behaviour. Which this pull request does.
This change is the final step in improving the semantics of
zx_cprng_draw. Now the syscall always generates the requested number of
bytes. If the syscall would have failed to generate the requested number
of bytes, the syscall either terminates the entire operating system or
terminates the calling process, depending on whether the error is a
result of the kernel misbehaving or the userspace program misbehaving.
