Rollup of 6 pull requests#157461
Closed
jhpratt wants to merge 13 commits into
Closed
Conversation
These methods return `io::Result` but did not document why they can fail or, importantly, that a child terminated by a signal is reported through its `ExitStatus` rather than as an `Err`. Add `# Errors` sections describing the common reasons spawning a child can fail (program not found, missing permission, resource exhaustion) and clarifying that a running child which exits unsuccessfully or is killed by a signal is not an error: those methods still return `Ok` and the outcome is reflected in the resulting `ExitStatus`.
…rrow-suggestion, r=mejrs Suppress E0621 perpetual borrow suggestion Fixes rust-lang#156682 E0621 suggests `&'a mut Buffer<'a>` when you write `&mut Buffer<'a>` and the compiler wants a named lifetime on the outer reference. That ties both lifetimes together and makes the value unusable after the call. Usually it's not the info that the user actually needs. When the suggested fix would produce `&'a [mut] T` where `'a` also appears inside `T`, with the changes being implemented on this PR we now suppress the `help:` suggestion and instead emit a `help:` linking to the nomicon's borrow-splitting chapter, which explains the actual fix. Detection uses the pre-fold parameter type and only fires for mutable references, avoiding false positives on trait objects (`&dyn Foo` folds to `&'a (dyn Foo + 'a)`) and shared references (`&'a S<'a>` is often intentional). What we had before the changes: ``` help: add explicit lifetime `'a` to the type of `buffer` | 5 | pub fn foo<'a>(buffer: &'a mut Buffer<'a>) { | ++ ``` What we are going to have now after: ``` error[E0621]: explicit lifetime required in the type of `buffer` | 5 | buffer.buf = &mut buffer.buf[..]; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ lifetime `'a` required | = help: see <https://doc.rust-lang.org/nomicon/borrow-splitting.html> for more information about lifetime errors related to mutable references ```
…c, r=wesleywiser fix armv7a-none-eabihf tier doc I found that PR rust-lang#146522 promoted `armv7a-none-eabihf` from Tier 3 to Tier 2, updating the target spec, `armv7a-none-eabi.md` and `platform-support.md`, but missed updating `arm-none-eabi.md`. The target remained listed under Tier 3 in that file. So I move `armv7a-none-eabihf` from Tier 3 to Tier 2 in `arm-none-eabi.md`, merging it with the existing `armv7a-none-eabi` entry. This makes the documentation consistent with the actual tier in the target spec and `platform-support.md`. r? @wesleywiser
…-errors, r=LawnGnome
Document error conditions for `Command::{spawn, output, status}`
Fixes rust-lang#150361.
`Command::spawn`, `Command::output`, and `Command::status` all return `io::Result`, but the docs never explain *why* they can fail, and they do not mention the (easy to get wrong) distinction between a failure to spawn and a child that runs but exits unsuccessfully or is killed by a signal.
This adds an `# Errors` section to each method:
- **`spawn`** describes the common reasons spawning fails — the program not being found, lacking permission to execute it (e.g. not executable, or blocked by a policy such as `seccomp`), and the OS being unable to create the process due to resource exhaustion. It also clarifies that an error is only returned for failures *while spawning*; once the child has started, anything that happens to it (including signals) is reported through its `ExitStatus`.
- **`output`** and **`status`** refer back to `spawn` for the spawn failures, and explicitly note that a child which exits unsuccessfully or is terminated by a signal is **not** an error — they still return `Ok`, with the outcome reflected in the resulting `ExitStatus`.
The error conditions and the signal/`ExitStatus` behavior were confirmed by `@bjorn3` in the issue discussion.
Docs-only change; no code blocks were added or modified, and all intra-doc links (`io::Error`, `ExitStatus`, `Output`, `spawn`) follow link patterns already used in this module.
r? libs
…rfonthey,ChrisDenton std tests: avoid duplicating thread-local machinery Under `cfg(test)` we have two copies of the standard library loaded, including two copies of all its global variables. Something about how that interacts with rust-lang#148799 results in memory leaks on windows-gnu targets, which are [caught by Miri](https://rust-lang.zulipchat.com/#narrow/channel/269128-miri/topic/Miri.20test-libstd.20Failure.20.282026-06.29/near/599991435). I'm not sure if it's worth debugging this. It's easier to just avoid duplicating the thread-local machinery. (This is something we had already done in the past, and then at some point stopped doing as Miri showed no more problems with the duplicate machinery. Now the problems are back.) Cc @joboet @ChrisDenton
…=mejrs Make distinction between crate-level attributes that are warned vs errored r? @mejrs This is a follow-up to rust-lang#157377 (comment) This PR makes all unstable crate-level attributes error on incorrect targets. To make the diff more helpful, I'd recommend reviewing the two commits separately. * The first commit introduces the infra & makes all crate-level attributes a warning, the commit should have no effect * The second commit undoes some changes from the first commit, to make all unstable crate-level attributes error
rustbot
added
A-attributes
Member
Author
|
@bors r+ rollup=never p=5 |
Contributor
rust-bors
Bot
added
S-waiting-on-bors
Contributor
|
⌛ Testing commit a99c4c7 with merge 2bd0a28... Workflow: https://github.com/rust-lang/rust/actions/runs/26995526261 |
rust-bors Bot
pushed a commit
that referenced
this pull request
Jun 5, 2026
Rollup of 6 pull requests Successful merges: - #156892 (Suppress E0621 perpetual borrow suggestion) - #157135 (fix armv7a-none-eabihf tier doc) - #157360 (Document error conditions for `Command::{spawn, output, status}`) - #157416 (std tests: avoid duplicating thread-local machinery) - #157418 (NVPTX: Add @kulst to the target maintainers) - #157443 (Make distinction between crate-level attributes that are warned vs errored)
rust-bors
Bot
added
S-waiting-on-author
Contributor
|
PR #157416, which is a member of this rollup, was unapproved. This rollup was thus unapproved. Auto build was cancelled due to unapproval. Cancelled workflows: |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
8 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Successful merges:
Command::{spawn, output, status}#157360 (Document error conditions forCommand::{spawn, output, status})r? @ghost
Create a similar rollup