coverage: Explicitly test the coverage maps produced by codegen/LLVM
Our existing coverage tests verify the output of end-to-end coverage reports, but we don't have any way to test the specific mapping information (code regions and their associated counters) that are emitted by `rustc_codegen_llvm` and LLVM. That makes it harder to to be confident in changes that would modify those mappings (whether deliberately or accidentally).
This PR addresses that by adding a new `coverage-map` test suite that does the following:
- Compiles test files to LLVM IR assembly (`.ll`)
- Feeds those IR files to a custom tool (`src/tools/coverage-dump`) that extracts and decodes coverage mappings, and prints them in a more human-readable format
- Checks the output of that tool against known-good snapshots
---
I recommend excluding the last commit while reviewing the main changes, because that last commit is just ~40 test files copied over from `tests/run-coverage`, plus their blessed coverage-map snapshots and a readme file. Those snapshots aren't really intended to be checked by hand; they're mostly there to increase the chances that an unintended change to coverage maps will be observable (even if it requires relatively specific circumstances to manifest).
Rollup of 7 pull requests
Successful merges:
- #113510 (Document soundness of Integer -> Pointer -> Integer conversions in `const` contexts.)
- #114412 (document our assumptions about symbols provided by the libc)
- #114813 (explain why we can mutate the FPU control word)
- #115523 (improve `AttrTokenStream`)
- #115536 (interpret: make MemPlace, Place, Operand types private to the interpreter)
- #115540 (Support debuginfo for custom MIR.)
- #115563 (llvm-wrapper: adapt for LLVM API change)
r? `@ghost`
`@rustbot` modify labels: rollup
support `{disable,enable}-patch-binaries-for-nix` in configure.py
Provide the control of `patch-binaries-for-nix` flag from configure.py without requiring manual editing.
It's useful when:
bf1e3f31f9/src/bootstrap/bootstrap.py (L661-L667)
Retry download of rustc-perf in opt-dist
This should help resolving spurious network errors. It also increases the timeout for the archive download.
r? `@Mark-Simulacrum`
We compile each test file to LLVM IR assembly, and then pass that IR to a
dedicated program that can decode LLVM coverage maps and print them in a more
human-readable format. We can then check that output against known-good
snapshots.
This test suite has some advantages over the existing `run-coverage` tests:
- We can test coverage instrumentation without needing to run target binaries.
- We can observe subtle improvements/regressions in the underlying coverage
mappings that don't make a visible difference to coverage reports.
Add an allow attribute suggestion along with the implied by suggestion
This PR adds an `#[allow(...)]` attribute hep suggestion along with the implied by suggestion:
```diff
note: `-W dead-code` implied by `-W unused`
+ help: to override `-W unused` add `#[allow(dead_code)]`
```
This PR also adds the `OnceHelp` lint level (similar to `OnceNote`) to only put the help message one time, like the implied note.
Related to https://github.com/rust-lang/rust/issues/114030
Rollup of 3 pull requests
Successful merges:
- #115478 (Emit unused doc comment warnings for pat and expr fields)
- #115490 (rustdoc: update comment in search.js for #107629)
- #115503 (Migrate GUI colors test to original CSS color format)
r? `@ghost`
`@rustbot` modify labels: rollup
make it more clear what 'Tier 2' (without host tools) means
When saying that Rust "builds official binary releases for each tier 2 target", it's not at all clear that this does not mean we build a compiler and cargo for that target.
[rustdoc] Fix type based search
Fixes https://github.com/rust-lang/rust/issues/114522.
The problem was a bit more tricky than I originally thought it would be: we only kept type ID and generics in short, but as soon as there was a full path in the user query, the element didn't get an ID anymore because the ID map didn't know about `x::y` (although it knew about `y`). So for this first problem, I instead always pass the element name to get the ID.
Then a new problem occurred: we actually needed to check if paths matched, otherwise whatever the path, as long as the "end types" match, it's all good. meaning, we needed to add path information, but to do so, we needed it to be added into the search index directly as there was no mapping between `"p"` and `"q"`.
I hope this explanation makes sense to someone else than me. ^^'
r? `@notriddle`
Skip rendering metadata strings from include_str!/include_bytes!
The const rendering code in rustdoc completely ignores consts from expansions, but the compiler was rendering all consts. So some consts (namely those from `include_bytes!`) were rendered then ignored.
Most of the diff here is from moving `print_const_expr` from rustdoc into `rustc_hir_pretty` so that it can be used in rustdoc and when building rmeta files.