Added one more test (two files) showing coverage of generics and unused
functions across crates.
Created and referenced new Issues, as requested.
Added comments.
Added a note about the possible effects of compiler options on LLVM
coverage maps.
Fixes multiple issue with counters, with simplification
Includes a change to the implicit else span in ast_lowering, so coverage
of the implicit else no longer spans the `then` block.
Adds coverage for unused closures and async function bodies.
Fixes: #78542
Adding unreachable regions for known MIR missing from coverage map
Cleaned up PR commits, and removed link-dead-code requirement and tests
Coverage no longer depends on Issue #76038 (`-C link-dead-code` is
no longer needed or enforced, so MSVC can use the same tests as
Linux and MacOS now)
Restrict adding unreachable regions to covered files
Improved the code that adds coverage for uncalled functions (with MIR
but not-codegenned) to avoid generating coverage in files not already
included in the files with covered functions.
Resolved last known issue requiring --emit llvm-ir workaround
Fixed bugs in how unreachable code spans were added.
Tested and validate results for panic unwind, panic abort, assert!()
macro, TerminatorKind::Assert (for example, numeric overflow), and
async/await.
Implemented a previous documented idea to change Assert handling to be
the same as FalseUnwind and Goto, so it doesn't get its own
BasicCoverageBlock anymore. This changed a couple of coverage regions,
but I validated those changes are not any worse than the prior results,
and probably help assure some consistency (even if some people might
disagree with how the code region is consistently computed).
Fixed issue with async/await. AggregateKind::Generator needs to be
handled like AggregateKind::Closure; coverage span for the outer async
function should not "cover" the async body, which is actually executed
in a separate "closure" MIR.
Fix `unknown-crate` when using -Z self-profile with rustdoc
... by removing a duplicate `crate_name` field in `interface::Config`,
making it clear that rustdoc should be passing it to `config::Options` instead.
Unblocks https://github.com/rust-lang/rustc-perf/issues/797.
Revert "Auto merge of #79209
r? `@nikomatsakis`
This has caused some issues (#79560) so better to revert and try to come up with a proper fix without rush.
Rustdoc: JSON backend experimental impl, with new tests.
Based on #75114 by `@P1n3appl3`
The first commit is all of #75114, but squased to 1 commit, as that was much easier to rebase onto master.
The git history is a mess, but I think I'll edit it after review, so it's obvious whats new.
## Still to do
- [ ] Update docs.
- [ ] Add bless option to tests.
- [ ] Add test option for multiple files in same crate.
- [ ] Decide if the tests should check for json to be equal or subset.
- [ ] Go through the rest of the review for the original pr. (This is open because the test system is done(ish), but stuff like [not using a hashmap](https://github.com/rust-lang/rust/pull/75114#discussion_r519474420) and [using `CRATE_DEF_INDEX` ](https://github.com/rust-lang/rust/pull/75114#discussion_r519470764) hasn't)
I'm also sure how many of these we need to do before landing on nightly, as it would be nice to get this in tree, so it isn't effected by churn like #79125, #79041, #79061
r? `@jyn514`
Pretty printing would add a `r#` prefix to raw identifiers, which was
not correct. In general I think this change makes sense -
pretty-printing is for showing to the *user*, `item_name` is suitable to
pass to resolve.
Do not show negative polarity trait implementations in diagnostic messages for similar implementations
This fixes#79458.
Previously, this code:
```rust
#[derive(Clone)]
struct Foo<'a, T> {
x: &'a mut T,
}
```
would have suggested that `<&mut T as Clone>` was an implementation that was found. This is due to the fact that the standard library now has `impl<'_, T> !Clone for &'_ mut T`, and explicit negative polarity implementations were not filtered out in diagnostic output when suggesting similar implementations.
This PR fixes this issue by filtering out negative polarity trait implementations in `find_similar_impl_candidates` within `rustc_trait_selection::traits::error_reporting::InferCtxtPrivExt<'tcx>`. It also adds a UI regression test for this issue and fixes UI tests that had incorrectly been modified to expect the invalid output.
r? `@scottmcm`
Use true previous lint level when detecting overriden forbids
Previously, cap-lints was ignored when checking the previous forbid level, which
meant that it was a hard error to do so. This is different from the normal
behavior of lints, which are silenced by cap-lints; if the forbid would not take
effect regardless, there is not much point in complaining about the fact that we
are reducing its level.
It might be considered a bug that even `--cap-lints deny` would suffice to
silence the error on overriding forbid, depending on if one cares about failing
the build or precisely forbid being set. But setting cap-lints to deny is quite
odd and not really done in practice, so we don't try to handle it specially.
This also unifies the code paths for nested and same-level scopes. However, the
special case for CLI lint flags is left in place (introduced by #70918) to fix
the regression noted in #70819. That means that CLI flags do not lint on forbid
being overridden by a non-forbid level. It is unclear whether this is a bug or a
desirable feature, but it is certainly inconsistent. CLI flags are a
sufficiently different "type" of place though that this is deemed out of scope
for this commit.
r? `@pnkfelix` perhaps?
cc #77713 -- not marking as "Fixes" because of the lack of proper unused attribute handling in this PR
Add wasm32 support to inline asm
There is some contention around inline asm and wasm, and I really only made this to figure out the process of hacking on rustc, but I figured as long as the code existed, it was worth uploading.
cc `@Amanieu`
Respond to comments and start adding tests
Fix re-exports and extern-crate
Add expected output tests
Add restricted paths
Format
Fix: associated methods missing in output
Ignore stripped items
Mark stripped items
removing them creates dangling references
Fix tests and update conversions
Don't panic if JSON backend fails to create a file
Fix attribute error in JSON testsuite
Move rustdoc-json to rustdoc/
This way it doesn't have to build rustc twice. Eventually it should
probably get its own suite, like rustdoc-js, but that can be fixed in a
follow-up.
Small cleanups
Don't prettify json before printing
This fully halves the size of the emitted JSON.
Add comments
[BREAKING CHANGE] rename version -> crate_version
[BREAKING CHANGE] rename source -> span
Use exhaustive matches
Don't qualify imports for DefId
Rename clean::{ItemEnum -> ItemKind}, clean::Item::{inner -> kind}
Fix Visibility conversion
clean::Visability was changed here:
https://github.com/rust-lang/rust/pull/77820/files#diff-df9f90aae0b7769e1eb6ea6f1d73c1c3f649e1ac48a20e169662a8930eb427beL1467-R1509
More churn catchup
Format
Remove const_fn_feature_flags test
## Overview
Helps with #76268
I found `const_fn_feature_flags` is targeting feature-gate and remove it.
r? ``@matklad``
Fix intra-doc links for `Self` on cross-crate items and primitives
- Remove the difference between `parent_item` and `current_item`; these
should never have been different.
- Remove `current_item` from `resolve` and `variant_field` so that
`Self` is only substituted in one place at the very start.
- Resolve the current item as a `DefId`, not a `HirId`. This is what
actually fixed the bug.
Hacks:
- `clean` uses `TypedefItem` when it _really_ should be
`AssociatedTypeItem`. I tried fixing this without success and hacked
around it instead (see comments)
- This second-guesses the `to_string()` impl since it wants
fully-qualified paths. Possibly there's a better way to do this.
