Skip to content

Rollup of 7 pull requests - #99439

Closed
matthiaskrgr wants to merge 14 commits into
rust-lang:masterfrom
matthiaskrgr:rollup-oz7hgih
Closed

Rollup of 7 pull requests#99439
matthiaskrgr wants to merge 14 commits into
rust-lang:masterfrom
matthiaskrgr:rollup-oz7hgih

Conversation

@matthiaskrgr

Copy link
Copy Markdown
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

beyarkayand others added 14 commits July 13, 2022 18:02
This documentation-only change clarifies how the user can get the
string representation of the output of a command.
The `stdout` and `stderr` members of `std::process::Output` from `std::process::Command` return a Vec<u8>, which is not always what the user wants.
For simple cases like printing `stderr` iff the `std::process::ExitStatus`
is non-zero, it's useful to get the string representation of this `Vec<u8>`.
This can be done via `String::from_utf8_lossy`, but it's not clear that this
is possible from the documentation without first searching the internet for
an answer.
Link to playground: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=8189f65dc4b354a643311af2cea5b230
This is needed for my Ubuntu 22.04 box due to a slight change in gdb
output. The fix is similar to the fix in rust-lang#95063.
Improves the compiler error backtrace information, as shown in rust-lang#99363,
by using `span_bug` instead of `bug`.
New output:
```
build/aarch64-apple-darwin/stage1/bin/rustc /tmp/test.rs --edition=2021
error: internal compiler error: compiler/rustc_middle/src/ty/closure.rs:185:25: Unexpected type Opaque(DefId(0:5 ~ test[db0f]::main::T::{opaque#0}), []) for `Field` projection
--> /tmp/test.rs:11:27
|
11 | let Foo((a, b)) = foo;
| ^^^
thread 'rustc' panicked at 'Box<dyn Any>', /Users/jmq/src/forked/rust/compiler/rustc_errors/src/lib.rs:1331:9
stack backtrace:
```
(Remainder of output truncated.)
The restriction that success ordering must be at least as strong as its
failure ordering in compare-exchange operations was lifted in rust-lang#98383.
docs: show how to stringify the output of Command
This documentation-only change clarifies how the user can get the string representation of the output of a command.
The `stdout` and `stderr` members of `std::process::Output` from `std::process::Command` return a Vec<u8>, which is not always what the user wants.
For simple cases like printing `stderr` iff the `std::process::ExitStatus` is non-zero, it's useful to get the string representation of this `Vec<u8>`. This can be done via `String::from_utf8_lossy`, but it's not clear that this is possible from the documentation without first searching the internet for an answer.
Link to playground: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=8189f65dc4b354a643311af2cea5b230
Use split_once in FromStr docs
Current implementation:
```rust
fn from_str(s: &str) -> Result<Self, Self::Err> {
let coords: Vec<&str> = s.trim_matches(|p| p == '(' || p == ')' )
.split(',')
.collect();
let x_fromstr = coords[0].parse::<i32>()?;
let y_fromstr = coords[1].parse::<i32>()?;
Ok(Point { x: x_fromstr, y: y_fromstr })
}
```
Creating the vector is not necessary, `split_once` does the job better.
Alternatively we could also remove `trim_matches` with `strip_prefix` and `strip_suffix`:
```rust
let (x, y) = s
.strip_prefix('(')
.and_then(|s| s.strip_suffix(')'))
.and_then(|s| s.split_once(','))
.unwrap();
```
The question is how much 'correctness' is too much and distracts from the example. In a real implementation you would also not unwrap (or originally access the vector without bounds checks), but implementing a custom Error and adding a `From<ParseIntError>` and implementing the `Error` trait adds a lot of code to the example which is not relevant to the `FromStr` trait.
use body's param-env when checking if type needs drop
The type comes from the body, so we should be using the body's param-env, as opposed to the ADT's param env, because we know less in the latter compared to the former.
Fixesrust-lang#99375
…pnkfelix
Fix debuginfo tests.
This is needed for my Ubuntu 22.04 box due to a slight change in gdb
output. The fix is similar to the fix in rust-lang#95063.
Use span_bug for unexpected field projection type
Improves the compiler error backtrace information, as shown in rust-lang#99363,
by using `span_bug` instead of `bug`.
New output:
```
build/aarch64-apple-darwin/stage1/bin/rustc /tmp/test.rs --edition=2021
error: internal compiler error: compiler/rustc_middle/src/ty/closure.rs:185:25: Unexpected type Opaque(DefId(0:5 ~ test[db0f]::main::T::{opaque#0}), []) for `Field` projection
--> /tmp/test.rs:11:27
|
11 | let Foo((a, b)) = foo;
| ^^^
thread 'rustc' panicked at 'Box<dyn Any>', /Users/jmq/src/forked/rust/compiler/rustc_errors/src/lib.rs:1331:9
stack backtrace:
```
(Remainder of output truncated.)
Update invalid atomic ordering lint
The restriction that success ordering must be at least as strong as its
failure ordering in compare-exchange operations was lifted in rust-lang#98383.
…=Mark-Simulacrum
Stabilize `core::task::ready!`
This stabilizes `core::task::ready!` for Rust 1.64. The FCP for stabilization was just completed here rust-lang#70922 (comment). Thanks!
Closesrust-lang#70922
cc/ `@rust-lang/libs-api`
@rustbotrustbot added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. rollup A PR which is a rollup labels Jul 18, 2022
@matthiaskrgr

Copy link
Copy Markdown
MemberAuthor

@bors r+ rollup=never p=7

@bors

bors commented Jul 18, 2022

Copy link
Copy Markdown
Collaborator

📌 Commit f3816dd has been approved by matthiaskrgr

It is now in the queue for this repository.

@borsbors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Jul 18, 2022
@bors

bors commented Jul 19, 2022

Copy link
Copy Markdown
Collaborator

⌛ Testing commit f3816dd with merge b24f27b6f5b5386dd47fccff20a647dbb51982bd...

@bors

bors commented Jul 19, 2022

Copy link
Copy Markdown
Collaborator

💔 Test failed - checks-actions

@borsbors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jul 19, 2022
@rust-log-analyzer

Copy link
Copy Markdown
Collaborator

The job x86_64-msvc-1 failed! Check out the build log: (web)(plain)

Click to see the possible cause of the failure (guessed by this bot)
Test executable failed (exit code: 101).
stderr:
thread 'main' panicked at 'assertion failed: `(left == right)`
left: `"hello\r\n"`,
right: `"hello\n"`', src\process.rs:19:1
stack backtrace:
0: 0x7ff76a48825a - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h50f847d2350461a9
1: 0x7ff76a4a6148 - core::fmt::write::h41197486a296c229
2: 0x7ff76a483469 - <std::io::error::Error as core::fmt::Display>::fmt::h2505adad9b70e7f2
3: 0x7ff76a48ab56 - std::panicking::default_hook::h43d61a3b1a287298
4: 0x7ff76a48a74f - std::panicking::default_hook::h43d61a3b1a287298
5: 0x7ff76a48b184 - std::panicking::rust_panic_with_hook::h71bee4f126409eea
6: 0x7ff76a48b06d - <std::panicking::begin_panic_handler::StrPanicPayload as core::panic::BoxMeUp>::get::hff17e89982af574f
7: 0x7ff76a488ef7 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h50f847d2350461a9
8: 0x7ff76a48ad00 - rust_begin_unwind
9: 0x7ff76a4ac335 - core::panicking::panic_fmt::h3b29e36fe8c3fc8c
10: 0x7ff76a4a5471 - core::panicking::assert_failed_inner::h0428aec34d11c8e3
11: 0x7ff76a473f2a - std::rt::lang_start::hebd1800a918147eb
12: 0x7ff76a477123 - std::rt::lang_start::hebd1800a918147eb
13: 0x7ff76a476fa9 - std::rt::lang_start::hebd1800a918147eb
14: 0x7ff76a4729a6 - std::rt::lang_start::hebd1800a918147eb
15: 0x7ff76a4713f9 - __ImageBase
16: 0x7ff76a47199c - std::rt::lang_start::hebd1800a918147eb
17: 0x7ff76a480c13 - std::rt::lang_start_internal::h45d07f31fc722f69
18: 0x7ff76a471980 - std::rt::lang_start::hebd1800a918147eb
19: 0x7ff76a477206 - main
20: 0x7ff76a4aaac4 - invoke_main
at D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:78
21: 0x7ff76a4aaac4 - __scrt_common_main_seh
at D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288
22: 0x7fff425e7974 - BaseThreadInitThunk
23: 0x7fff4328a2f1 - RtlUserThreadStart
failures:
src\process.rs - process::Command (line 461)
src\process.rs - process::Command (line 461)
test result: FAILED. 1078 passed; 1 failed; 20 ignored; 0 measured; 0 filtered out; finished in 41.24s
error: test failed, to rerun pass '--doc'
finished in 550.518 seconds
Build completed unsuccessfully in 0:52:02
make: *** [Makefile:70: ci-subset-1] Error 1

Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

rollupA PR which is a rollupS-waiting-on-reviewStatus: Awaiting review from the assignee but also interested parties.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.T-libsRelevant to the library team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

10 participants

@matthiaskrgr@bors@rust-log-analyzer@rustbot@beyarkay@compiler-errors@nnethercote@Dav1dde@tmiasko@yoshuawuyts