Skip to content

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
Collaborator

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
Collaborator

bors commented Jul 19, 2022

⌛ Testing commit f3816dd with merge b24f27b6f5b5386dd47fccff20a647dbb51982bd...

@bors
Copy link
Collaborator

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