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 10 pull requests #93616

Closed
wants to merge 24 commits into from

Conversation

matthiaskrgr
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

ehuss and others added 24 commits December 26, 2021 20:32
Continue supporting -Z instrument-coverage for compatibility for now,
but show a deprecation warning for it.

Update uses and documentation to use the -C option.

Move the documentation from the unstable book to stable rustc
documentation.
llvm-tools-preview is still experimental, so document it as such, and
don't use it in the examples.
…VM versions

The instrument-coverage option is stable; the details of the profile
data format are not.

Recommend llvm-tools-preview as the preferred alternative to obtain a
compatible version of the LLVM tools, rather than finding LLVM tools
elsewhere.
Co-authored-by: Mark Rousskov <mark.simulacrum@gmail.com>
…tions

These options primarily exist to work around bugs, and those bugs have
largely been fixed. Avoid stabilizing them, so that we don't have to
support them indefinitely.
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.
The following *-unwind ABIs are now supported:
- "C-unwind"
- "cdecl-unwind"
- "stdcall-unwind"
- "fastcall-unwind"
- "vectorcall-unwind"
- "thiscall-unwind"
- "aapcs-unwind"
- "win64-unwind"
- "sysv64-unwind"
- "system-unwind"
…overage, r=wesleywiser

Stabilize `-Z instrument-coverage` as `-C instrument-coverage`

(Tracking issue for `instrument-coverage`: rust-lang#79121)

This PR stabilizes support for instrumentation-based code coverage, previously provided via the `-Z instrument-coverage` option. (Continue supporting `-Z instrument-coverage` for compatibility for now, but show a deprecation warning for it.)

Many, many people have tested this support, and there are numerous reports of it working as expected.

Move the documentation from the unstable book to stable rustc documentation. Update uses and documentation to use the `-C` option.

Addressing questions raised in the tracking issue:

> If/when stabilized, will the compiler flag be updated to -C instrument-coverage? (If so, the -Z variant could also be supported for some time, to ease migrations for existing users and scripts.)

This stabilization PR updates the option to `-C` and keeps the `-Z` variant to ease migration.

> The Rust coverage implementation depends on (and automatically turns on) -Z symbol-mangling-version=v0. Will stabilizing this feature depend on stabilizing v0 symbol-mangling first? If so, what is the current status and timeline?

This stabilization PR depends on rust-lang#90128 , which stabilizes `-C symbol-mangling-version=v0` (but does not change the default symbol-mangling-version).

> The Rust coverage implementation implements the latest version of LLVM's Coverage Mapping Format (version 4), which forces a dependency on LLVM 11 or later. A compiler error is generated if attempting to compile with coverage, and using an older version of LLVM.

Given that LLVM 13 has now been released, requiring LLVM 11 for coverage support seems like a reasonable requirement. If people don't have at least LLVM 11, nothing else breaks; they just can't use coverage support. Given that coverage support currently requires a nightly compiler and LLVM 11 or newer, allowing it on a stable compiler built with LLVM 11 or newer seems like an improvement.

The [tracking issue](rust-lang#79121) and the [issue label A-code-coverage](https://github.com/rust-lang/rust/labels/A-code-coverage) link to a few open issues related to `instrument-coverage`, but none of them seem like showstoppers. All of them seem like improvements and refinements we can make after stabilization.

The original `-Z instrument-coverage` support went through a compiler-team MCP at rust-lang/compiler-team#278 . Based on that, `@pnkfelix` suggested that this needed a stabilization PR and a compiler-team FCP.
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.
Add more *-unwind ABI variants

The following *-unwind ABIs are now supported:
- "C-unwind"
- "cdecl-unwind"
- "stdcall-unwind"
- "fastcall-unwind"
- "vectorcall-unwind"
- "thiscall-unwind"
- "aapcs-unwind"
- "win64-unwind"
- "sysv64-unwind"
- "system-unwind"

cc `@rust-lang/wg-ffi-unwind`
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.
…st, r=jsha

Update browser-ui-test version

The puppeteer version update is limited because new versions has some "interesting" flaws.

r? `@jsha`
…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. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. rollup A PR which is a rollup labels Feb 3, 2022
@matthiaskrgr
Copy link
Member Author

@bors r+ rollup=never p=10

@bors
Copy link
Contributor

bors commented Feb 3, 2022

📌 Commit d9c74a6 has been approved by matthiaskrgr

@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
@rust-log-analyzer
Copy link
Collaborator

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

Click to see the possible cause of the failure (guessed by this bot)
  IMAGE: x86_64-gnu-tools
##[endgroup]
From https://github.com/rust-lang/rust
 * branch              master     -> FETCH_HEAD
Searching for toolstate changes between 1be5c8f90912c446ecbdc405cbc4a89f9acd20fd and d30e3e661d9cc46e6c66af81f5150d69d54436e0
Rustdoc was updated
##[group]Run src/ci/scripts/verify-channel.sh
src/ci/scripts/verify-channel.sh
shell: /usr/bin/bash --noprofile --norc -e -o pipefail {0}
env:
---
Removing intermediate container ea5e8230d47f
 ---> 981986f8cbf1
Step 11/13 : RUN npm install -g browser-ui-test@0.7.0 --unsafe-perm=true
 ---> Running in f873d0c0f261
npm WARN deprecated puppeteer@3.3.0: Version no longer supported. Upgrade to @latest

> puppeteer@3.3.0 install /node-v14.4.0-linux-x64/lib/node_modules/browser-ui-test/node_modules/puppeteer
> node install.js



Chromium (756035) downloaded to /node-v14.4.0-linux-x64/lib/node_modules/browser-ui-test/node_modules/puppeteer/.local-chromium/linux-756035
added 49 packages from 86 contributors in 7.298s
Removing intermediate container f873d0c0f261
 ---> ab096bef5772
Step 12/13 : ENV RUST_CONFIGURE_ARGS   --build=x86_64-unknown-linux-gnu   --save-toolstates=/tmp/toolstate/toolstates.json
---
Successfully built 7dfe26736cd5
Successfully tagged rust-ci:latest
Built container sha256:7dfe26736cd5c4a0a73acdee49645e08c37bd818c1e10d5323c310cd731fe7d3
Uploading finished image to https://ci-caches.rust-lang.org/docker/a4c684db48535f57528cdd21253d8c15716f7121004c370c2ef9bf59ff9399512222798f9e2717aef35869aa31277fbb2aec48fb767ea8d7306761745af95dfb
upload failed: - to s3://rust-lang-ci-sccache2/docker/a4c684db48535f57528cdd21253d8c15716f7121004c370c2ef9bf59ff9399512222798f9e2717aef35869aa31277fbb2aec48fb767ea8d7306761745af95dfb Unable to locate credentials
[CI_JOB_NAME=x86_64-gnu-tools]
---
-hello dup fd
-

The actual stdout differed from the expected stdout.
Actual stdout saved to /tmp/compiletestUPtJ0X/fs.stage-id.stdout

-hello dup fd
+error: unsupported operation: can't call foreign function: readdir64
+   --> /checkout/library/std/src/sys/unix/fs.rs:482:33
---
+
 

The actual stderr differed from the expected stderr.
Actual stderr saved to /tmp/compiletestUPtJ0X/fs.stage-id.stderr
To only update this specific test, also pass `--test-args fs.rs`

error: 2 errors occurred comparing output.
status: exit status: 1
status: exit status: 1
command: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools-bin/miri" "tests/run-pass/fs.rs" "-L" "/tmp/compiletestUPtJ0X" "--target=x86_64-unknown-linux-gnu" "--error-format" "json" "-C" "prefer-dynamic" "-o" "/tmp/compiletestUPtJ0X/fs.stage-id" "-A" "unused" "--edition" "2018" "-Astable-features" "--sysroot" "/home/user/.cache/miri/HOST" "-Zmiri-disable-isolation" "-L" "/tmp/compiletestUPtJ0X/fs.stage-id.aux"
------------------------------------------

------------------------------------------
stderr:
---
......... (50/59)
.........  (59/59)


/checkout/src/test/rustdoc-gui/sidebar-mobile.goml sidebar-mobile... FAILED
[ERROR] (line 42) Error: Evaluation failed: different Y values: 543 != 542.96875: for command `assert-position: (".block.keyword li:nth-child(1)", {"y": 542.96875})`
Build completed unsuccessfully in 0:00:17

@matthiaskrgr matthiaskrgr deleted the rollup-6z0tsmf branch February 13, 2022 00:53
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-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. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.