And restored missing error message from llvm-cov show
And since some CI builds disable LLVM assertions (which disables the
--debug option in llvm-cov show), I check to see if LLVM assertions are
disabled, and if so, I don't add --debug and don't check the counter
file diffs.
More portable way to make python 2/3 portable.
Strip Args line (with hardcoded paths) from debug counters output.
Ignore diff failures from llvm-cov debug output files ("counters"
files), since generic function instantiations will appear in those files
with mangled names. (Sadly, the demangler is apparently not applied to
the debug output.)
Implementing the Graph traits for the BasicCoverageBlock
graph.
optimized replacement of counters with expressions plus new BCB graphviz
* Avoid adding coverage to unreachable blocks.
* Special case for Goto at the end of the body. Make it non-reportable.
Improved debugging and formatting options (from env)
Don't automatically add counters to BCBs without CoverageSpans. They may
still get counters but only if there are dependencies from
other BCBs that have spans, I think.
Make CodeRegions optional for Counters too. It is
possible to inject counters (`llvm.instrprof.increment` intrinsic calls
without corresponding code regions in the coverage map. An expression
can still uses these counter values.
Refactored instrument_coverage.rs -> instrument_coverage/mod.rs, and
then broke up the mod into multiple files.
Compiling with coverage, with the expression optimization, works on
the json5format crate and its dependencies.
Refactored debug features from mod.rs to debug.rs
reverse binding order in matches to allow the subbinding of copyable fields in bindings after @
Fixes#69971
### TODO
- [x] Regression tests
r? `@oli-obk`
Rollup of 15 pull requests
Successful merges:
- #76718 (Move Vec UI tests to unit tests when possible)
- #78093 (Clean up docs for 'as' keyword)
- #78425 (Move f64::NAN ui tests into `library`)
- #78465 (Change as_str → to_string in proc_macro::Ident::span() docs)
- #78584 (Add keyboard handling to the theme picker menu)
- #78716 (Array trait impl comment/doc fixes)
- #78727 ((rustdoc) fix test for trait impl display)
- #78733 (fix a couple of clippy warnings:)
- #78735 (Simplify the implementation of `get_mut` (no unsafe))
- #78738 (Move range in ui test to ops test in library/core)
- #78739 (Fix ICE on type error in async function)
- #78742 (make intern_const_alloc_recursive return error)
- #78756 (Update cargo)
- #78757 (Improve and clean up some intra-doc links)
- #78758 (Fixed typo in comment)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
(rustdoc) fix test for trait impl display
The test checks that parameters and return values with `impl Trait` types are correctly generated in rustdoc's output.
In essence, the previous version of the test checked the absence of values that would never be generated by rustdoc, so it could basically never fail. These values were adjusted to the expected output and are now required to exist in rustdoc's output. See https://github.com/rust-lang/rust/issues/55201#issuecomment-716182474 for a detailed explanation of the reasoning behind the changes.
Note that the output of rustdoc for `impl Trait`s in parameters and return values did not change since the inital test creation, so this PR only modifies the test.
Closes#55201
Add keyboard handling to the theme picker menu
This PR is mostly designed to bring the theme picker closer to feature parity with the menu bar from docs.rs. Though the rustdoc theme picker is technically already usable from the keyboard, it's really weird that arrow keys work on some of the menus, but not all of them, in the exact same page.
Change as_str → to_string in proc_macro::Ident::span() docs
There is no `as_str` function on Ident any more.
Also change it to an intra doc link while we're at it.
Move Vec UI tests to unit tests when possible
Helps with #76268.
I'm moving the tests using `Vec` or `VecDeque`.
````@rustbot```` modify labels: A-testsuite C-cleanup T-libs
Bump actions/checkout to version 2
This was recommended by GitHub Support to try reducing the things that could've caused #78743. I checked the changelog and there should be no practical impact for us (we already set an explicit fetch-depth).
r? `@Mark-Simulacrum`
`crate::` -> `core::`
It looks weird to have `crate::` in the link text and we use the actual
crate name everywhere else.
If anyone is curious, I used this Vim command to update all the links:
%s/\(\s\)\[`crate::\(.*\)`\]/\1[`core::\2`](crate::\2)/g
This was recommended by GitHub Support to try reducing the things that
could've caused #78743. I checked the changelog and there should be no
practical impact for us (we already set an explicit fetch-depth).
Provide diagnostic suggestion in ExprUseVisitor Delegate
The [Delegate trait](981346fc07/compiler/rustc_typeck/src/expr_use_visitor.rs (L28-L38)) currently use `PlaceWithHirId` which is composed of Hir `Place` and the
corresponding expression id.
Even though this is an accurate way of expressing how a Place is used,
it can cause confusion during diagnostics.
Eg:
```
let arr : [String; 5];
let [a, ...] = arr;
^^^ E1 ^^^ = ^^E2^^
```
Here `arr` is moved because of the binding created E1. However, when we
point to E1 in diagnostics with the message `arr` was moved, it can be
confusing. Rather we would like to report E2 to the user.
Closes: https://github.com/rust-lang/project-rfc-2229/issues/20
r? `@ghost`
Provide diagnostic suggestion in ExprUseVisitor Delegate
The [Delegate trait](981346fc07/compiler/rustc_typeck/src/expr_use_visitor.rs (L28-L38)) currently use `PlaceWithHirId` which is composed of Hir `Place` and the
corresponding expression id.
Even though this is an accurate way of expressing how a Place is used,
it can cause confusion during diagnostics.
Eg:
```
let arr : [String; 5];
let [a, ...] = arr;
^^^ E1 ^^^ = ^^E2^^
```
Here `arr` is moved because of the binding created E1. However, when we
point to E1 in diagnostics with the message `arr` was moved, it can be
confusing. Rather we would like to report E2 to the user.
Closes: https://github.com/rust-lang/project-rfc-2229/issues/20
r? `@ghost`
Add lint for 'field_reassign_with_default` #568
changelog: Add lint for field_reassign_with_default that checks if mutable object + field modification is used to edit a binding initialized with Default::default() instead of struct constructor.
Fixes#568
Notes:
- Checks for reassignment of one or more fields of a binding initialized with Default::default().
- Implemented using EarlyLintPass, might be future proofed better with LateLintPass.
- Does not trigger if Default::default() is used via another type implementing Default.
- This is a re-open of [PR#4761](https://github.com/rust-lang/rust-clippy/pull/4761), but I couldn't figure out how to re-open that one so here's a new one with the requested changes :S
