-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rollup of 9 pull requests #83497
Closed
Closed
Rollup of 9 pull requests #83497
Conversation
This file contains 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
Proper Unix terminology is "exit status" (vs "wait status"). "exit code" is imprecise on Unix and therefore unclear. (As far as I can tell, "exit code" is correct terminology on Windows.) This new wording is unfortunately inconsistent with the identifier names in the Rust stdlib. It is the identifier names that are wrong, as discussed at length in eg https://doc.rust-lang.org/nightly/std/process/struct.ExitStatus.html https://doc.rust-lang.org/nightly/std/os/unix/process/trait.ExitStatusExt.html Unfortunately for API stability reasons it would be a lot of work, and a lot of disruption, to change the names in the stdlib (eg to rename `std::process::ExitStatus` to `std::process::ChildStatus` or something), but we should fix the message output. Many (probably most) readers of these messages about exit statuses will be users and system administrators, not programmers, who won't even know that Rust has this wrong terminology. So I think the right thing is to fix the documentation (as I have already done) and, now, the terminology in the implementation. This is a user-visible change to the behaviour of all Rust programs which run Unix subprocesses. Hopefully no-one is matching against the exit status string, except perhaps in tests. Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
Looks like I missed the lack of these "and"s. Acked-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
Which thus missed the point of the change: `rustdoc` already bundled documentation for methods accessible through one layer of `Deref`, it now has been enhanced to keep recursing 🙂
Fixes rust-lang#83469 We need to return an `Annotatable::Stmt` if we were passed an `Annotatable::Stmt`
…doc, r=jyn514 [rustdoc] Don't document stripped items in JSON renderer. Fixes rust-lang#80664, see [my comment there](rust-lang#80664 (comment)) for why Note that we already do something similar in `convert_item`: https://github.com/rust-lang/rust/blob/bb4cdf8ec034dca5c056ec9295f38062e5b7e871/src/librustdoc/json/conversions.rs#L28-L31 `@rustbot` modify labels: +T-rustdoc +A-rustdoc-json r? `@jyn514` cc `@CraftSpider`
Refactor rust-lang#82270 as lint instead of an error This PR fixes several issues with rust-lang#82270 which generated an error when `.intel_syntax` or `.att_syntax` was used in inline assembly: - It is now a warn-by-default lint instead of an error. - The lint only triggers on x86. `.intel_syntax` and `.att_syntax` are only valid on x86. - The lint no longer provides machine-applicable suggestions for two reasons: - These changes should not be made automatically since changes to assembly code can be very subtle. - The template string is not always just a string: it can contain macro invocation (`concat!`), raw strings, escape characters, etc. cc `@asquared31415`
…ietroalbini Fix bootstrap tests on beta Forward-porting a fix from the beta branch, which led to test failure on beta. r? `@pietroalbini`
Add docs for Vec::from functions Part of rust-lang#51430
…, r=joshtriplett ExitStatus: print "exit status: {}" rather than "exit code: {}" on unix Proper Unix terminology is "exit status" (vs "wait status"). "exit code" is imprecise on Unix and therefore unclear. (As far as I can tell, "exit code" is correct terminology on Windows.) This new wording is unfortunately inconsistent with the identifier names in the Rust stdlib. It is the identifier names that are wrong, as discussed at length in eg https://doc.rust-lang.org/nightly/std/process/struct.ExitStatus.html https://doc.rust-lang.org/nightly/std/os/unix/process/trait.ExitStatusExt.html Unfortunately for API stability reasons it would be a lot of work, and a lot of disruption, to change the names in the stdlib (eg to rename `std::process::ExitStatus` to `std::process::ChildStatus` or something), but we should fix the message output. Many (probably most) readers of these messages about exit statuses will be users and system administrators, not programmers, who won't even know that Rust has this wrong terminology. So I think the right thing is to fix the documentation (as I have already done) and, now, the terminology in the implementation. This is a user-visible change to the behaviour of all Rust programs which run Unix subprocesses. Hopefully no-one is matching against the exit status string, except perhaps in tests.
… r=kennytm ExitStatusExt: Fix missing word in two docs messages Looks like I missed the lack of these "and"s.
Fix patch note about rust-lang#80653 not mentioning nested nor recursive Which thus missed the point of the change: `rustdoc` already bundled documentation for methods accessible through one layer of `Deref`, it has now been enhanced to keep recursing 🙂 r? `@jyn514`
Mark asm tests as requiring LLVM 10.0.1
…=petrochenkov Don't ICE when using `#[global_alloc]` on a non-item statement Fixes rust-lang#83469 We need to return an `Annotatable::Stmt` if we were passed an `Annotatable::Stmt`
@bors r+ rollup=never p=5 |
📌 Commit 3c34424 has been approved by |
bors
added
the
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
label
Mar 25, 2021
⌛ Testing commit 3c34424 with merge baaf24842bc77051da7b59904e57b09da528418c... |
The job Click to see the possible cause of the failure (guessed by this bot)
|
💔 Test failed - checks-actions |
bors
removed
the
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
label
Mar 26, 2021
bors
added
the
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
label
Mar 26, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
rollup
A PR which is a rollup
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
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:
asm!
#82270 as lint instead of an error)Deref
traits #80653 not mentioning nested nor recursive)#[global_alloc]
on a non-item statement #83486 (Don't ICE when using#[global_alloc]
on a non-item statement)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup