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 #93621

Merged
merged 14 commits into from
Feb 3, 2022
Merged

Rollup of 7 pull requests #93621

merged 14 commits into from
Feb 3, 2022

Conversation

JohnTitor
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

ehuss and others added 14 commits December 26, 2021 20:32
Compiler panics should be rare - when they do occur, we want the report
filed by the user to contain as much information as possible. This is
especially important when the panic is due to an incremental compilation
bug, since we may not have enough information to reproduce it.

This PR sets `RUST_BACKTRACE=full` inside `rustc` if the user has not
explicitly set `RUST_BACKTRACE`. This is more verbose than
`RUST_BACKTRACE=1`, but this may make it easier to debug incremental
compilation issues. Users who find this too verbose can still manually
set `RUST_BACKTRACE` before invoking the compiler.

This only affects `rustc` (and any tool using `rustc_driver::install_ice_hook`).
It does *not* affect any user crates or the standard library -
backtraces will continue to be off by default in any application
*compiled* by rustc.
rustdoc: Fix ICE report

The ICE report in rustdoc was confusing because it was returning an argument parse error:

```
thread 'rustc' panicked at 'aborting due to `-Z treat-err-as-bug=1`', compiler/rustc_errors/src/lib.rs:1212:27
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

error: internal compiler error: unexpected panic

error: Unrecognized option: 'crate-version'
```

This is because the ICE reporter was trying to parse the arguments as rustc, not rustdoc.  Since an argument error is a fatal error, it was early-exiting with the argument error due to unwinding.

This changes it to be a more primitive scan of the arguments. The arguments being checked are pretty simple, and only have a small handful of forms that are easy to check for.

It now looks like this:

```
thread 'rustc' panicked at 'aborting due to `-Z treat-err-as-bug=1`', compiler/rustc_errors/src/lib.rs:1212:27
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

error: internal compiler error: unexpected panic

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md

note: rustc 1.59.0-dev running on x86_64-apple-darwin

note: compiler flags: --crate-type lib -Z treat-err-as-bug

note: some of the compiler flags provided by cargo are hidden

query stack during panic:
end of query stack
```

It still says `rustc`, but I can live with that.
…race, r=oli-obk

Deduplicate lines in long const-eval stack trace

Lemme know if this is kinda overkill, lol.

Fixes rust-lang#92796
Factor convenience functions out of main printer implementation

The pretty printer in rustc_ast_pretty has a section of methods commented "Convenience functions to talk to the printer". This PR pulls those out to a separate module. This leaves pp.rs with only the minimal API that is core to the pretty printing algorithm.

I found this separation to be helpful in https://github.com/dtolnay/prettyplease because it makes clear when changes are adding some fundamental new capability to the pretty printer algorithm vs just making it more convenient to call some already existing functionality.
Make rustc use `RUST_BACKTRACE=full` by default

Compiler panics should be rare - when they do occur, we want the report
filed by the user to contain as much information as possible. This is
especially important when the panic is due to an incremental compilation
bug, since we may not have enough information to reproduce it.

This PR sets `RUST_BACKTRACE=full` inside `rustc` if the user has not
explicitly set `RUST_BACKTRACE`. This is more verbose than
`RUST_BACKTRACE=1`, but this may make it easier to debug incremental
compilation issues. Users who find this too verbose can still manually
set `RUST_BACKTRACE` before invoking the compiler.

This only affects `rustc` (and any tool using `rustc_driver::install_ice_hook`).
It does *not* affect any user crates or the standard library -
backtraces will continue to be off by default in any application
*compiled* by rustc.
…r=yaahc

fix: Remove extra newlines from junit output

This PR fixes extra newline in junit output rust-lang#93454
…r, r=oli-obk

Correct incorrect description of preorder traversals

The internal documentation for the `Preorder` type gave an incorrect description (the description is not even correct for the example provided, since C is visited after one of its successors). This corrects the description, and adds in a sentence explaining more precisely how the traversals are performed.
@rustbot rustbot added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. rollup A PR which is a rollup labels Feb 3, 2022
@JohnTitor
Copy link
Member Author

@bors r+ p=7 rollup=never

@bors
Copy link
Contributor

bors commented Feb 3, 2022

📌 Commit 38adea9 has been approved by JohnTitor

@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 Feb 3, 2022
@bors
Copy link
Contributor

bors commented Feb 3, 2022

⌛ Testing commit 38adea9 with merge 4e8fb74...

@bors
Copy link
Contributor

bors commented Feb 3, 2022

☀️ Test successful - checks-actions
Approved by: JohnTitor
Pushing 4e8fb74 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Feb 3, 2022
@bors bors merged commit 4e8fb74 into rust-lang:master Feb 3, 2022
@rustbot rustbot added this to the 1.60.0 milestone Feb 3, 2022
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (4e8fb74): comparison url.

Summary: This benchmark run did not return any relevant results.

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

@rustbot label: -perf-regression

@JohnTitor JohnTitor deleted the rollup-1bcud0x branch February 3, 2022 21:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. rollup A PR which is a rollup S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet