Add support for LLVM coverage mapping format versions 5 and 6
This PR cherry-pick's Swatinem's initial commit in unsubmitted PR #90047.
My additional commit augments Swatinem's great starting point, but adds full support for LLVM
Coverage Mapping Format version 6, conditionally, if compiling with LLVM 13.
Version 6 requires adding the compilation directory when file paths are
relative, and since Rustc coverage maps use relative paths, we should
add the expected compilation directory entry.
Note, however, that with the compilation directory, coverage reports
from `llvm-cov show` can now report file names (when the report includes
more than one file) with the full absolute path to the file.
This would be a problem for test results, but the workaround (for the
rust coverage tests) is to include an additional `llvm-cov show`
parameter: `--compilation-dir=.`
When recovering from a `:` in a pattern, use adequate AST pattern
If the suggestion to use `::` instead of `:` in the pattern isn't correct, a second resolution error will be emitted.
`Resolver::next_node_id` converts a `u32` to a `usize` (which is
possibly bigger), does a checked add, and then converts the result back
to a `u32`. The `usize` conversion completely subverts the checked add!
This commit removes the conversion to/from `usize`.
Instead we run `RemoveFalseEdges` and `RemoveUninitDrops` at the
appropriate time. The extra `SimplifyCfg` avoids visiting unreachable
blocks during `RemoveUninitDrops`.
Otherwise dataflow state will propagate along false edges and cause
things to be marked as maybe init unnecessarily. These should be
separate, since `SimplifyBranches` also makes `if true {} else {}` into
a `goto`, which means we wouldn't lint anything in the `else` block.
This commit augments Swatinem's initial commit in uncommitted PR #90047,
which was a great starting point, but did not fully support LLVM
Coverage Mapping Format version 6.
Version 6 requires adding the compilation directory when file paths are
relative, and since Rustc coverage maps use relative paths, we should
add the expected compilation directory entry.
Note, however, that with the compilation directory, coverage reports
from `llvm-cov show` can now report file names (when the report includes
more than one file) with the full absolute path to the file.
This would be a problem for test results, but the workaround (for the
rust coverage tests) is to include an additional `llvm-cov show`
parameter: `--compilation-dir=.`
CTFE: support assert_zero_valid and assert_uninit_valid
This ensures the implementation of all three type-based assert_ intrinsics remains consistent in Miri.
`assert_inhabited` recently got stabilized in https://github.com/rust-lang/rust/pull/90896 (meaning stable `const fn` can call it), so do the same with these other intrinsics.
Cc ```@rust-lang/wg-const-eval```
Refactor EmitterWriter::emit_suggestion_default
Makes progress towards https://github.com/rust-lang/rust/issues/89979
Split into 2 commits:
* the first commit is purely a refactor and I verified that `./x.py test src/test/ui --stage 1` and `./x.py test src/test/rustdoc-ui --stage 1` continue to pass on this commit.
* ~~the second commit removes the empty trailing line from diff style suggestions.~~ - I discovered an issue with this so its just the refactor now.
r? diagnostics
This commit is intended to follow the stabilization disposition of the
FCP that has now finished in #84223. This stabilizes the ability to flag
thread local initializers as `const` expressions which enables the macro
to generate more efficient code for accessing it, notably removing
runtime checks for initialization.
More information can also be found in #84223 as well as the tests where
the feature usage was removed in this PR.
Closes#84223
Take a LocalDefId in expect_*item.
Items and item-likes are always HIR owners.
When trying to find such nodes, there is no ambiguity, the `LocalDefId` and the `HirId::owner` always match.
In such cases, `local_def_id_to_hir_id` does not carry any meaningful information, so we can just skip calling it altogether.
Nothing else makes sense, and there is no "danger" in doing so, as it only does something if there are const bounds, which are unstable. This used to happen implicitly via the inferctxt before, which was much more fragile.
