Report coverage `0` of dead blocks
Fixes: #84018
With `-Z instrument-coverage`, coverage reporting of dead blocks
(for example, blocks dropped because a conditional branch is dropped,
based on const evaluation) is now supported.
If `instrument-coverage` is enabled, `simplify::remove_dead_blocks()`
finds all dropped coverage `Statement`s and adds their `code_region`s as
`Unreachable` coverage `Statement`s to the `START_BLOCK`, so they are
still included in the coverage map.
Check out the resulting changes in the test coverage reports in this PR (in [commit 1](0b0d293c7c)).
r? `@tmandry`
cc: `@wesleywiser`
CTFE inbounds-error-messages tweak
* use CheckInAllocMsg::PointerArithmeticTest for ptr_offset error
* nicer errors for some null pointer cases
r? `@oli-obk`
Coverage instruments closure bodies in macros (not the macro body)
Fixes: #84884
This solution might be considered a compromise, but I think it is the
better choice.
The results in the `closure.rs` test correctly resolve all test cases
broken as described in #84884.
One test pattern (in both `closure_macro.rs` and
`closure_macro_async.rs`) was also affected, and removes coverage
statistics for the lines inside the closure, because the closure
includes a macro. (The coverage remains at the callsite of the macro, so
we lose some detail, but there isn't a perfect choice with macros.
Often macro implementations are split across the macro and the callsite,
and there doesn't appear to be a single "right choice" for which body
should be covered. For the current implementation, we can't do both.
The callsite is most likely to be the preferred site for coverage.
r? `@tmandry`
cc: `@wesleywiser`
Removes unneeded check of `#[no_coverage]` in mapgen
There is an anticipated feature request to support a compiler flag that
only adds coverage for specific files (or perhaps mods). As I thought
about where that change would need to be supported, I realized that
checking the attribute in mapgen (for unused functions) was unnecessary.
The unused functions are only synthesized if they have MIR coverage, and
functions with the `no_coverage` attribute will not have been
instrumented with MIR coverage statements in the first place.
New tests confirm this.
Also, while adding tests, I updated resolved comments and FIXMEs in
other tests, and expanded comments and tests on one remaining issue that
is still not resolved.
r? `@tmandry`
cc: `@wesleywiser`
Rollup of 11 pull requests
Successful merges:
- #84409 (Ensure TLS destructors run before thread joins in SGX)
- #84500 (Add --run flag to compiletest)
- #84728 (Add test for suggestion to borrow unsized function parameters)
- #84734 (Add `needs-unwind` and beginning of support for testing `panic=abort` std to compiletest)
- #84755 (Allow using `core::` in intra-doc links within core itself)
- #84871 (Disallows `#![feature(no_coverage)]` on stable and beta (using standard crate-level gating))
- #84872 (Wire up tidy dependency checks for cg_clif)
- #84896 (Handle incorrect placement of parentheses in trait bounds more gracefully)
- #84905 (CTFE engine: rename copy → copy_intrinsic, move to intrinsics.rs)
- #84953 (Remove unneeded call to with_default_session_globals in rustdoc highlight)
- #84987 (small nits)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
CTFE engine: rename copy → copy_intrinsic, move to intrinsics.rs
The `copy` name is confusing for this function because we also have `copy_op` which is pretty different. I hope `copy_intrinsic` is clearer. Also `step.rs` should really just contain the main loop and opcode dispatch, so move this helper function to a more appropriate place.
r? ``````@oli-obk``````
Disallows `#![feature(no_coverage)]` on stable and beta (using standard crate-level gating)
Fixes: #84836
Removes the function-level feature gating solution originally implemented, and solves the same problem using `allow_internal_unstable`, so normal crate-level feature gating mechanism can still be used (which disallows the feature on stable and beta).
I tested this, building the compiler with and without `CFG_DISABLE_UNSTABLE_FEATURES=1`
With unstable features disabled, I get the expected result as shown here:
```shell
$ ./build/x86_64-unknown-linux-gnu/stage1/bin/rustc src/test/run-make-fulldeps/coverage/no_cov_crate.rs
error[E0554]: `#![feature]` may not be used on the dev release channel
--> src/test/run-make-fulldeps/coverage/no_cov_crate.rs:2:1
|
2 | #![feature(no_coverage)]
| ^^^^^^^^^^^^^^^^^^^^^^^^
error: aborting due to previous error
For more information about this error, try `rustc --explain E0554`.
```
r? ````@Mark-Simulacrum````
cc: ````@tmandry```` ````@wesleywiser````
And adds tests to validate it still works.
There is an anticipated feature request to support a compiler flag that
only adds coverage for specific files (or perhaps mods). As I thought
about where that change would need to be supported, I realized that
checking the attribute in mapgen (for unused functions) was unnecessary.
The unused functions are only synthesized if they have MIR coverage, and
functions with the `no_coverage` attribute will not have been
instrumented with MIR coverage statements in the first place.
New tests confirm this.
Also, while adding tests, I updated resolved comments and FIXMEs in
other tests.
Fixes: #84884
This solution might be considered a compromise, but I think it is the
better choice.
The results in the `closure.rs` test correctly resolve all test cases
broken as described in #84884.
One test pattern (in both `closure_macro.rs` and
`closure_macro_async.rs`) was also affected, and removes coverage
statistics for the lines inside the closure, because the closure
includes a macro. (The coverage remains at the callsite of the macro, so
we lose some detail, but there isn't a perfect choice with macros.
Often macro implementations are split across the macro and the callsite,
and there doesn't appear to be a single "right choice" for which body
should be covered. For the current implementation, we can't do both.
The callsite is most likely to be the preferred site for coverage.
I applied this fix to all `MacroKinds`, not just `Bang`.
I'm trying to resolve an issue of lost coverage in a
`MacroKind::Attr`-based, function-scoped macro. Instead of only
searching for a body_span that is "not a function-like macro" (that is,
MacroKind::Bang), I'm expanding this to all `MacroKind`s. Maybe I should
expand this to `ExpnKind::Desugaring` and `ExpnKind::AstPass` (or
subsets, depending on their sub-kinds) as well, but I'm not sure that's
a good idea.
I'd like to add a test of the `Attr` macro on functions, but I need time
to figure out how to constract a good, simple example without external
crate dependencies. For the moment, all tests still work as expected (no
change), this new commit shouldn't have a negative affect, and more
importantly, I believe it will have a positive effect. I will try to
confirm this.
Deduplicate ParamCandidates with the same value except for bound vars
Fixes#84398
This is kind of a hack. I wonder if we can get other types of candidates that are the same except for bound vars. This won't be a problem with Chalk, since we don't really need to know that there are two different "candidates" if they both give the same final substitution.
r? `@nikomatsakis`
lazify backtrace formatting for delayed diagnostics
Formatting backtraces causes debug info to be parsed, which is superfluous work if the delayed bugs get cleared later.
Lazifying them results in these speedups for the UI testsuite:
| | debuginfo = 0 | debuginfo = 1 | debuginfo = 2 |
|-------|---------------|---------------|---------------|
| eager | 31.59s | 37.55s | 42.64s |
| lazy | 30.44s | 30.86s | 34.07s |
Fix#84467 linker_args with --target=sparcv9-sun-solaris
Trying to cross-compile for sparcv9-sun-solaris
getting a error message for -zignore
Introduced when -z -ignore was seperated here
22d0ab0
No formatting done
Reproduce
``` bash
rustup target add sparcv9-sun-solaris
cargo new --bin hello && cd hello && cargo run --target=sparcv9-sun-solaris
```
config.toml
[target.sparcv9-sun-solaris]
linker = "gcc"
This commit implements both the native linking modifiers infrastructure
as well as an initial attempt at the individual modifiers from the RFC.
It also introduces a feature flag for the general syntax along with
individual feature flags for each modifier.
This defers backtrace formatting to the point where we
actually want to flush delayed diagnostics. If they are discarded
before that point then we can avoid invoking the backtrace formatting
machinery which will parse debug info and symbol tables.
for debuginfo=2 this leads to a 20% walltime reduction of the UI testsuite
Do not ICE on invalid const param
When encountering a path that can't have generics, do not call
`generics_of`. This would happen when writing something like
`path::this_is_a_mod<const_val>`.
Fix#84831.
Remove `rustc_middle::mir::interpret::CheckInAllocMsg::NullPointerTest`
Removing it per https://github.com/rust-lang/rust/pull/84842#discussion_r625589674: it's a dead enum variant.
Note that `PointerArithmeticTest` also seems dead:
```
$ rg -F PointerArithmeticTest -C5
compiler/rustc_middle/src/mir/interpret/error.rs
169-
170-/// Details of why a pointer had to be in-bounds.
171-#[derive(Debug, Copy, Clone, TyEncodable, TyDecodable, HashStable)]
172-pub enum CheckInAllocMsg {
173- MemoryAccessTest,
174: PointerArithmeticTest,
175- InboundsTest,
176-}
177-
178-impl fmt::Display for CheckInAllocMsg {
179- /// When this is printed as an error the context looks like this
--
182- write!(
183- f,
184- "{}",
185- match *self {
186- CheckInAllocMsg::MemoryAccessTest => "memory access",
187: CheckInAllocMsg::PointerArithmeticTest => "pointer arithmetic",
188- CheckInAllocMsg::InboundsTest => "inbounds test",
189- }
190- )
191- }
192-}
```
Not sure if that is also desirable to be removed, however.
using allow_internal_unstable (as recommended)
Fixes: #84836
```shell
$ ./build/x86_64-unknown-linux-gnu/stage1/bin/rustc src/test/run-make-fulldeps/coverage/no_cov_crate.rs
error[E0554]: `#![feature]` may not be used on the dev release channel
--> src/test/run-make-fulldeps/coverage/no_cov_crate.rs:2:1
|
2 | #![feature(no_coverage)]
| ^^^^^^^^^^^^^^^^^^^^^^^^
error: aborting due to previous error
For more information about this error, try `rustc --explain E0554`.
```
Deduplicate native libs before they are passed to the linker
Stop spamming the linker with the same native library over and over again, if they directly follow from each other. This would help prevent [this situation](https://github.com/MSxDOS/ntapi/issues/2).
Issue #38460 has been open since 2016 so I think it's worth making an incomplete fix that at least addresses the most common symptom and without otherwise changing how Rust handles native libs. This PR is intended to be easy to revert (if necessary) when a more permanent fix is implemented.
Retain data in vectorized registers for longer
This seems to be a mild performance improvement on the keccak crate at least, though not sure it'll show up more broadly.
When encountering a path that can't have generics, do not call
`generics_of`. This would happen when writing something like
`path::this_is_a_mod<const_val>`.
Fix#84831.
Update BARE_TRAIT_OBJECT and ELLIPSIS_INCLUSIVE_RANGE_PATTERNS to errors in Rust 2021
This addresses https://github.com/rust-lang/rust/pull/81244 by updating two lints to errors in the Rust 2021 edition.
r? `@estebank`
