Skip to content
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 7 pull requests #99439

Closed
wants to merge 14 commits into from

Conversation

matthiaskrgr
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

beyarkay and 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.

Fixes rust-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!

Closes rust-lang#70922

cc/ `@rust-lang/libs-api`
@rustbot rustbot 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
Member Author

@bors r+ rollup=never p=7

@bors
Copy link
Contributor

bors commented Jul 18, 2022

📌 Commit f3816dd has been approved by matthiaskrgr

It is now in the queue for this repository.

@bors bors 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
Copy link
Contributor

bors commented Jul 19, 2022

⌛ Testing commit f3816dd with merge b24f27b6f5b5386dd47fccff20a647dbb51982bd...

@bors
Copy link
Contributor

bors commented Jul 19, 2022

💔 Test failed - checks-actions

@bors bors 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
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 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. 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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants