Implement `TryFrom<&OsStr>` for `&str`
Recently when trying to work with `&OsStr` I was surprised to find this `impl` missing.
Since the `to_str` method already existed the actual implementation is fairly non-controversial, except for maybe the choice of the error type. I chose an opaque error here instead of something like `std::str::Utf8Error`, since that would already make a number of assumption about the underlying implementation of `OsStr`.
As this is a trait implementation, it is insta-stable, if I'm not mistaken?
Either way this will need an FCP.
I chose "1.64.0" as the version, since this is unlikely to land before the beta cut-off.
`@rustbot` modify labels: +T-libs-api
API Change Proposal: rust-lang/rust#99031 (accepted)
Add support for targets without unwinding in `mir-opt`, and improve `--bless` for it
The main goal of this PR is to add support for targets without unwinding support in the `mir-opt` test suite, by adding the `EMIT_MIR_FOR_EACH_PANIC_STRATEGY` comment. Similarly to 32bit vs 64bit, when that comment is present, blessed output files will have the `.panic-unwind` or `.panic-abort` suffix, and the right one will be chosen depending on the target's panic strategy.
The `EMIT_MIR_FOR_EACH_PANIC_STRATEGY` comment replaced all the `ignore-wasm32` comments in the `mir-opt` test suite, as those comments were added due to `wasm32` being a target without unwinding support. The comment was also added on other tests that were only executed on x86 but were still panic strategy dependent.
The `mir-opt` suite was then blessed, which caused a ton of churn as most of the existing output files had to be renamed and (mostly) duplicated with the abort strategy.
---
After [asking on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/mir-opt.20tests.20and.20panic.3Dabort), the main concern about this change is it'd make blessing the `mir-opt` suite even harder, as you'd need to both bless it with an unwinding target and an aborting target. This exacerbated the current situation, where you'd need to bless it with a 32bit and a 64bit target already.
Because of that, this PR also makes significant enhancements to `--bless` for the `mir-opt` suite, where it will automatically bless the suite four times with different targets, while requiring minimal cross-compilation.
To handle the 32bit vs 64bit blessing, there is now an hardcoded list of target mapping between 32bit and 64bit. The goal of the list is to find a related target that will *probably* work without requiring additional cross-compilation toolchains on the system. If a mapping is found, bootstrap will bless the suite with both targets, otherwise just with the current target.
To handle the panic strategy blessing (abort vs unwind), I had to resort to what I call "synthetic targets". For each of the target we're blessing (so either the current one, or a 32bit and a 64bit depending on the previous paragraph), bootstrap will extract the JSON spec of the target and change it to include `"panic-strategy": "abort"`. It will then build the standard library with this synthetic target, and bless the `mir-opt` suite with it.
As a result of these changes, blessing the `mir-opt` suite will actually bless it two or four times with different targets, ensuring all possible variants are actually blessed.
---
This PR is best reviewed commit-by-commit.
r? `@jyn514`
cc `@saethlin` `@oli-obk`
It might happen that a synthetic target name does not match one of the
hardcoded ones in std's build script, causing std to fail to build. This
commit changes the std build script avoid including the restricted-std
feature unconditionally when a synthetic target is being built.
Avoid unwind across `extern "C"` in `thread_local::fast_local`
This is a minimal fix for #112285, in case we want a simple patch that can be easily to backported if that's desirable.
*(Note: I have another broader cleanup which I've mostly omitted from here to avoid clutter, except for the `Cell` change, which isn't needed to fix UB, but simplifies safety comments).*
The only tier-1 target that this occurs on in a way that seems likely to cause problems in practice linux-gnu, although I believe some folks care about that platform somewhat 😉. I'm unsure how big of an issue this is. I've seen stuff like this behave quite badly, but there's a number of reasons to think this might actually be "fine in practice".
I've hedged my bets and assumed we'll backport this at least to beta but my feeling is that there's not enough evidence this is a problem worth backporting further than that.
### More details
This issue seems to have existed since `thread_local!`'s `const` init functionality was added. It occurs if you have a `const`-initialized thread local for a type that `needs_drop`, the drop panics, and you're on a target with support for static thread locals. In this case, we will end up defining an `extern "C"` function in the user crate rather than in libstd, and because the user crate will not have `#![feature(c_unwind)]` enabled, their panic will not be caught by an auto-inserted abort guard.
In practice, the actual situation where problems are likely[^ub] is somewhat narrower.
On most targets with static thread locals, we manage the TLS dtor list by hand (for reentrancy reasons among others). In these cases, while the users code may panic, we're calling it inside our own `extern "C"` (or `extern "system"`) function, which seems to (at least in practice) catch the panic and convert it to an abort.
However, on a few targets, most notably linux-gnu with recent glibc (but also fuchsia and redox), a tls dtor registration mechanism exists which we can actually use directly, [`__cxa_thread_atexit_impl`](https://github.com/rust-lang/rust/blob/master/library/std/src/sys/unix/thread_local_dtor.rs#L26-L36).
This is the case that seems most likely to be a cause for concern, as now we're passing a function to the system library and panicking out of it in a case where there are may not be Rust frames above it on the call stack (since it's running thread shutdown), and even if there were, it may not be prepared to handle such unwinding. If that's the case, it'd be bad.
Is it? Dunno. The fact that it's a `__cxa_*` function makes me think they probably have considered that the callback could throw but I have no evidence here and it doesn't seem to be written down anywhere, so it's just a guess. (I would not be surprised if someone comes into this thread to tell me how definitely-bad-news it is).
That said, as I said, all this is actually UB! If this isn't a "technically UB but fine in practice", but all bets are off if this is the kind of thing we are telling LLVM about.
[^ub]: This is UB so take that with a grain of salt -- I'm absolutely making assumptions about how the UB will behave "in practice" here, which is almost certainly a mistake.
QNX Neutrino: exponential backoff when fork/spawn needs a retry
Fixes#108594: When retrying, sleep with an exponential duration. When sleep duration is lower than minimum possible sleeping time, yield instead (this will not be often due to the exponential increase of duration).
Minimum possible sleeping time is determined using `libc::clock_getres` but only when spawn/fork failed the first time in a request. This is cached using a LazyLock.
CC `@gh-tr`
r? `@workingjubilee`
`@rustbot` label +O-neutrino
use c literals in compiler and library
Use c literals #108801 in compiler and library
currently blocked on:
* <strike>rustfmt: don't know how to format c literals</strike> nope, nightly one works.
* <strike>bootstrap</strike>
r? `@ghost`
`@rustbot` blocked
This fixes the behavior of sending EOF by pressing Ctrl+Z => Enter in a
windows console.
Previously, that would trip the unpaired surrogate error, whereas now we
correctly detect EOF.
This is not a library, so there's no reason for them to be `pub`.
Without doing this, compiling the test crates causes private dep
lint errors:
error: type `PathBuf` from private dependency 'std' in public interface
--> library/std/tests/common/mod.rs:26:5
|
26 | pub fn join(&self, path: &str) -> PathBuf {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: `-D exported-private-dependencies` implied by `-D warnings`
error: type `Path` from private dependency 'std' in public interface
--> library/std/tests/common/mod.rs:31:5
|
31 | pub fn path(&self) -> &Path {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^
error: could not compile `std` (test "create_dir_all_bare") due to 2 previous errors
This happens because Cargo passes `--extern 'priv:std=...` when
compiling the test crate.
I'm not sure if these warnings are desirable or not. They seem correct
in a very pedantic way (the dependency on `std` is not marked public,
since it's implicit), but also pointless (the test crate is not an API,
so who cares what it does).
Mark internal functions and traits unsafe to reflect preconditions
No semantics are changed in this PR; I only mark some functions and and a trait `unsafe` which already had implicit preconditions. Although it seems somewhat redundant for `numfmt::Part::Copy` to contain a `&[u8]` instead of a `&str`, given that all of its current consumers ultimately expect valid UTF-8. Is the type also intended to work for byte-slice formatting in the future?
Add creation time support to `FileTimes` on apple and windows
Adds support for setting file creation times on platforms which support changing it directly (currently only Apple and Windows). Based on top of #110093 (which was split from this PR).
ACP: rust-lang/libs-team#199 (currently still in progress)
Tracking issue: #98245
`@rustbot` label +T-libs-api -T-libs
Shorten even more panic temporary lifetimes
Followup to #104134. As pointed out by `@bjorn3` in https://github.com/rust-lang/rust/pull/104134#pullrequestreview-1425585948, there are other cases in the panic macros which would also benefit from dropping their non-Send temporaries as soon as possible, avoiding pointlessly holding them across an await point.
For the tests added in this PR, here are the failures you get today on master without the macro changes in this PR:
<details>
<summary>tests/ui/macros/panic-temporaries-2018.rs</summary>
```console
error: future cannot be sent between threads safely
--> tests/ui/macros/panic-temporaries-2018.rs:52:18
|
LL | require_send(panic_display());
| ^^^^^^^^^^^^^^^ future returned by `panic_display` is not `Send`
|
= help: within `impl Future<Output = ()>`, the trait `Send` is not implemented for `*const u8`
note: future is not `Send` as this value is used across an await
--> tests/ui/macros/panic-temporaries-2018.rs:35:31
|
LL | f(panic!("{}", NOT_SEND)).await;
| -------- ^^^^^- `NOT_SEND` is later dropped here
| | |
| | await occurs here, with `NOT_SEND` maybe used later
| has type `NotSend` which is not `Send`
note: required by a bound in `require_send`
--> tests/ui/macros/panic-temporaries-2018.rs:48:25
|
LL | fn require_send(_: impl Send) {}
| ^^^^ required by this bound in `require_send`
error: future cannot be sent between threads safely
--> tests/ui/macros/panic-temporaries-2018.rs:52:18
|
LL | require_send(panic_display());
| ^^^^^^^^^^^^^^^ future returned by `panic_display` is not `Send`
|
= help: within `NotSend`, the trait `Sync` is not implemented for `*const u8`
note: future is not `Send` as this value is used across an await
--> tests/ui/macros/panic-temporaries-2018.rs:35:31
|
LL | f(panic!("{}", NOT_SEND)).await;
| ---------------------- ^^^^^- the value is later dropped here
| | |
| | await occurs here, with the value maybe used later
| has type `&NotSend` which is not `Send`
note: required by a bound in `require_send`
--> tests/ui/macros/panic-temporaries-2018.rs:48:25
|
LL | fn require_send(_: impl Send) {}
| ^^^^ required by this bound in `require_send`
error: future cannot be sent between threads safely
--> tests/ui/macros/panic-temporaries-2018.rs:53:18
|
LL | require_send(panic_str());
| ^^^^^^^^^^^ future returned by `panic_str` is not `Send`
|
= help: within `impl Future<Output = ()>`, the trait `Send` is not implemented for `*const u8`
note: future is not `Send` as this value is used across an await
--> tests/ui/macros/panic-temporaries-2018.rs:40:36
|
LL | f(panic!((NOT_SEND, "...").1)).await;
| -------- ^^^^^- `NOT_SEND` is later dropped here
| | |
| | await occurs here, with `NOT_SEND` maybe used later
| has type `NotSend` which is not `Send`
note: required by a bound in `require_send`
--> tests/ui/macros/panic-temporaries-2018.rs:48:25
|
LL | fn require_send(_: impl Send) {}
| ^^^^ required by this bound in `require_send`
error: future cannot be sent between threads safely
--> tests/ui/macros/panic-temporaries-2018.rs:54:18
|
LL | require_send(unreachable_display());
| ^^^^^^^^^^^^^^^^^^^^^ future returned by `unreachable_display` is not `Send`
|
= help: within `impl Future<Output = ()>`, the trait `Send` is not implemented for `*const u8`
note: future is not `Send` as this value is used across an await
--> tests/ui/macros/panic-temporaries-2018.rs:45:31
|
LL | f(unreachable!(NOT_SEND)).await;
| -------- ^^^^^- `NOT_SEND` is later dropped here
| | |
| | await occurs here, with `NOT_SEND` maybe used later
| has type `NotSend` which is not `Send`
note: required by a bound in `require_send`
--> tests/ui/macros/panic-temporaries-2018.rs:48:25
|
LL | fn require_send(_: impl Send) {}
| ^^^^ required by this bound in `require_send`
error: future cannot be sent between threads safely
--> tests/ui/macros/panic-temporaries-2018.rs:54:18
|
LL | require_send(unreachable_display());
| ^^^^^^^^^^^^^^^^^^^^^ future returned by `unreachable_display` is not `Send`
|
= help: within `NotSend`, the trait `Sync` is not implemented for `*const u8`
note: future is not `Send` as this value is used across an await
--> tests/ui/macros/panic-temporaries-2018.rs:45:31
|
LL | f(unreachable!(NOT_SEND)).await;
| ---------------------- ^^^^^- the value is later dropped here
| | |
| | await occurs here, with the value maybe used later
| has type `&NotSend` which is not `Send`
note: required by a bound in `require_send`
--> tests/ui/macros/panic-temporaries-2018.rs:48:25
|
LL | fn require_send(_: impl Send) {}
| ^^^^ required by this bound in `require_send`
error: aborting due to 5 previous errors
```
</details>
<details>
<summary>tests/ui/macros/panic-temporaries.rs</summary>
```console
error: future cannot be sent between threads safely
--> tests/ui/macros/panic-temporaries.rs:42:18
|
LL | require_send(panic_display());
| ^^^^^^^^^^^^^^^ future returned by `panic_display` is not `Send`
|
= help: within `impl Future<Output = ()>`, the trait `Send` is not implemented for `*const u8`
note: future is not `Send` as this value is used across an await
--> tests/ui/macros/panic-temporaries.rs:35:31
|
LL | f(panic!("{}", NOT_SEND)).await;
| -------- ^^^^^- `NOT_SEND` is later dropped here
| | |
| | await occurs here, with `NOT_SEND` maybe used later
| has type `NotSend` which is not `Send`
note: required by a bound in `require_send`
--> tests/ui/macros/panic-temporaries.rs:38:25
|
LL | fn require_send(_: impl Send) {}
| ^^^^ required by this bound in `require_send`
error: future cannot be sent between threads safely
--> tests/ui/macros/panic-temporaries.rs:42:18
|
LL | require_send(panic_display());
| ^^^^^^^^^^^^^^^ future returned by `panic_display` is not `Send`
|
= help: within `NotSend`, the trait `Sync` is not implemented for `*const u8`
note: future is not `Send` as this value is used across an await
--> tests/ui/macros/panic-temporaries.rs:35:31
|
LL | f(panic!("{}", NOT_SEND)).await;
| ---------------------- ^^^^^- the value is later dropped here
| | |
| | await occurs here, with the value maybe used later
| has type `&NotSend` which is not `Send`
note: required by a bound in `require_send`
--> tests/ui/macros/panic-temporaries.rs:38:25
|
LL | fn require_send(_: impl Send) {}
| ^^^^ required by this bound in `require_send`
error: aborting due to 2 previous errors
```
</details>
r? bjorn3
add examples of port 0 binding behavior
Was trying to find the method to specify the IP address but not the port, and there wasn't information easily accessible about it in the `TcpListener` or `SocketAddr`. Adding examples to `TcpListener` and `UdpSocket` for clarity.
