Fix doc nits
Many tiny changes to stdlib doc comments to make them consistent (for example "Returns foo", rather than "Return foo"), adding missing periods, paragraph breaks, backticks for monospace style, and other minor nits.
Both these platforms have MSG_NOSIGNAL available, and we should set it for
socket writes in the event that the SIGPIPE handler has been reset to SIG_DFL
(i.e. terminate the process).
I've verified via a quick program at
https://github.com/sunshowers/msg-nosignal-test/ that even when the SIGPIPE
handler is reset to SIG_DFL, writes to closed sockets now error out with EPIPE.
(Under ordinary circumstances UDP writes won't cause MSG_NOSIGNAL.)
Use `#[rustfmt::skip]` on some `use` groups to prevent reordering.
`use` declarations will be reformatted in #125443. Very rarely, there is a desire to force a group of `use` declarations together in a way that auto-formatting will break up. E.g. when you want a single comment to apply to a group. #126776 dealt with all of these in the codebase, ensuring that no comments intended for multiple `use` declarations would end up in the wrong place. But some people were unhappy with it.
This commit uses `#[rustfmt::skip]` to create these custom `use` groups in an idiomatic way for a few of the cases changed in #126776. This works because rustfmt treats any `use` item annotated with `#[rustfmt::skip]` as a barrier and won't reorder other `use` items around it.
r? `@cuviper`
Rollup of 6 pull requests
Successful merges:
- #126908 (Use Cow<'static, str> for InlineAsmTemplatePiece::String)
- #127999 (Inject arm32 shims into Windows metadata generation)
- #128137 (CStr: derive PartialEq, Eq; add test for Ord)
- #128185 (Fix a span error when parsing a wrong param of function.)
- #128187 (Fix 1.80.0 version in RELEASES.md)
- #128189 (Turn an unreachable code path into an ICE)
r? `@ghost`
`@rustbot` modify labels: rollup
Inject arm32 shims into Windows metadata generation
I had been keen to eventually move to using windows-sys as a normal Cargo dependency. But for linking, compile times and other reasons that's unlikely to ever happen.
So if we're sticking with generated bindings then injecting any necessary missing type definitions (i.e. for the MS unsupported arm32) is simpler than defining whole functions ourselves just because we need to manually implement those types on a tier 3 platform. This also reduces the places we need to change when making changes to how we use `#[link]`.
r? libs
std: unsafe-wrap personality::gcc
Nothing seems obviously wrong with these implementations except for some unanswered questions. Admittedly, I don't want to burn excessive time on exceptional exception handlers. Thus this is mostly a brute-force syntactic wrapping and some comments where they seemed correct, creating another largely whitespace diff.
try-job: armhf-gnu
Fix connect timeout for non-linux targets, read readiness of socket connection, Read readiness to detect errors. `Fixes #127018`
Fixes#127018
Connect_timeout would call `poll` and check `pollfd.revents` for POLLHUP error, rather that checking readiness. This behavior was meant for Linux as it returns POLLHUP | POLLOUT | POLLERR in case of errors. But on targets that do not return POLLHUP in `pollfd.revents`, this would indicate a false success and result in this issue. To resolve this we will check readiness of socket using `getsockopt():` and return success from connect_timeout when there are no errors.
Changes were tested on Linux and an rtos.
Thank you.
Import `c_void` rather than using the full path
Follow up to #128092. As requested, this imports `c_void` in more places. I also fixed up some imports to use `core` for core types instead of `crate`. While that is not strictly necessary, I think ideally things in `sys/pal` should only depend on itself or core so that the code is less spaghetti. We're far away from that ideal at the moment but I can at least try to slowly move in that direction.
Also this forbids `unsafe_op_in_unsafe_fn` for library/std/src/sys/pal/windows by fixing up the remaining unsafe bits that are just punting their unsafe requirements onto the caller of the `unsafe` function (or definition macro).
<!--
r? workingjubilee
-->
Replace some `mem::forget`'s with `ManuallyDrop`
> but I would like to see a larger effort to replace all uses of `mem::forget`.
_Originally posted by `@saethlin` in https://github.com/rust-lang/rust/issues/127584#issuecomment-2226087767_
So,
r? `@saethlin`
Sorry, I have finished writing all of this before I got your response.
Fix build failure on vxworks #127084
PR to address issue #127084 .
1. Skip `reset_segpipe` for vxworks
2. Return unimplemented error for vxworks from settimes and lchown
3. Temporarily skip dirfd for vxworks
4. Add allow unused unsafe on read_at and write_at functions in unix/fs.rs
5. Using cfg disable ON_BROKEN_PIPE_FLAG_USED and on_broken_pipe_flag_used() for vxworks
6. Remove old crate::syscommon:🧵:min_stack() reference from process_vxworks.rs and update to set stack size of rtpthread
Thank you.
Fix return type of FileAttr methods on AIX target
At some point it seems `SystemTime::new` changed from returning `SystemTime` to `io::Result<SystemTime>`. This seems to have been addressed on other platforms, but was never changed for AIX.
This was caught by running
```
python3 x.py build --host x86_64-unknown-linux-gnu --target powerpc64-ibm-aix
```
Remove wrapper functions from c.rs
I'd like for the windows `c.rs` just to contain the basic platform definitions and not anything higher level unless absolutely necessary. So this removes some wrapper functions that weren't really necessary in any case. The functions are only used in a few places which themselves are relatively thin wrappers. The "interesting" bit is that we had an `AlertableIoFn` that abstracted over `ReadFileEx` and `WriteFileEx`. I've replaced this with a closure.
Also I removed an `#[allow(unsafe_op_in_unsafe_fn)]` while I was moving things around.
At some point it seems `SystemTime::new` changed from returning `SystemTime` to `io::Result<SystemTime>`. This seems to have been addressed on other platforms, but was never changed for AIX.
This was caught by running
```
python3 x.py build --host x86_64-unknown-linux-gnu --target powerpc64-ibm-aix
```
Clean up warnings + `unsafe_op_in_unsafe_fn` when building std for armv6k-nintendo-3ds
See #127747
ping `@AzureMarker` `@Meziu`
I could only find one instance needing an extra `unsafe` that was not also shared with many other `unix` targets (presumably these will get covered in larger sweeping changes, I didn't want to introduce churn that would potentially conflict with those). The one codepath I found is shared with `vita` however, so also pinging `@nikarh` `@pheki` `@zetanumbers` just to make sure they're aware of this change.
Also removed one unused import from `process_unsupported` which should simply fix the warning for any target that uses it.
Deal with invalid UTF-8 from `gai_strerror`
When the system is using a non-UTF-8 locale, the value will indeed not be UTF-8. That sucks for everyone involved, but is no reason for panic. We can "handle" this gracefully by just using from lossy, replacing the invalid UTF-8 with � and keeping the accidentally valid UTF-8. Good luck when debugging, but at least it's not a crash.
We already do this for `strerror_r`.
fixes#127563
When the system is using a non-UTF-8 locale, the value will indeed not
be UTF-8. That sucks for everyone involved, but is no reason for panic.
We can "handle" this gracefully by just using from lossy, replacing the
invalid UTF-8 with the ? and keeping the accidentally valid UTF-8.
Good luck when debugging, but at least it's not a crash.
We already do this for `strerror_r`.
Windows: move BSD socket shims to netc
On Windows we need to alter a few types so that they can be used in the cross-platform socket code. Currently these alterations are spread throughout the `c` module with some more in the `netc` module.
Let's gather all our BSD compatibility shims in the `netc` module so it's all in one place and easier to discover.
kmc-solid: `#![forbid(unsafe_op_in_unsafe_fn)]`
The path logic _should_ handle the forbiddance in the itron sources correctly, despite them being an "out-of-line" module.
unix: document unsafety for std `sig{action,altstack}`
I found many surprising elements here while trying to wrap a measly 5 functions with `unsafe`. I would rather not "just" mindlessly wrap this code with `unsafe { }`, so I decided to document it properly.
On Unix, this code covers the "create and setup signal handler" part of the stack overflow code, and serves as the primary safety boundary for the signal handler. It is rarely audited, very gnarly, and worth extra attention. It calls other unsafe functions defined in this module, but "can we correctly map the right memory, or find the right address ranges?" are separate questions, and get increasingly platform-specific. The question here is the more general "are we doing everything in the correct order, and setting up the handler in the correct way?"
As part of this audit, I noticed that we do some peculiar things that we should probably refrain from. However, I avoided making changes that I deemed might have a different final result in Rust programs. I did, however, reorder some events so that the signal handler is installed _after_ we install the alternate stack. We do not run much code between these events, but it is probably best if the timespan between the handler being available and the new stack being installed is 0 nanoseconds.
Safely enforce thread name requirements
The requirements for the thread name to be both UTF-8 and null terminated are easily enforced by a wrapper type so lets do that. The fact this used to be just a bare `CString` has tripped me up before because it was entirely safe to use a non UTF-8 `CString`.
Add Process support for UEFI
UEFI does not have an actual process. However, it does provide methods to launch and execute another UEFI image. Having process support is important since it is possible to run rust test suit using `Command::output` and is the first step towards being able to run it for UEFI.
Here is an overview of how the support is implemented.
- We create a copy of the SystemTable. This is required since at least OVMF seems to crash if the original system table is modified.
- Stdout and Stderr pipe works by registering a new `simple_text_output` Protocol and pointing the child system table to use those.
- `Stdio::Inherit` just points the console to the current running image console which seems to work with even 3 levels of process.
- `spawn` is left unimplemented since it does not make sense for UEFI architecture. Additionally, since https://github.com/rust-lang/rust/pull/105458 was merged, the `spawn` and `output` implementations are completely independent.
