coverage: Anonymize line numbers in `run-coverage` test snapshots
LLVM's coverage reporter always prints line numbers in its coverage reports.
For testing purposes this is slightly inconvenient, because it means that adding or removing a line in a test file causes all subsequent lines in the snapshot to change. That makes it harder to see the actually meaningful changes in the re-blessed snapshot.
---
This change fixes that by adding another normalization pass that replaces all line numbers in the coverage reports with `LL`, which is similar to what UI tests tell the compiler to do when emitting line numbers in error messages.
Remove conditional use of `Sharded` from query caches
`Sharded` is already a zero cost abstraction, so it shouldn't affect the performance of the single thread compiler if LLVM does its job.
r? `@cjgillot`
Only run MaybeInitializedPlaces dataflow once to elaborate drops
This pass allows forward dataflow analyses to modify the CFG depending on the dataflow state. This possibility is used for the `MaybeInitializedPlace` analysis in drop elaboration, to skip the dataflow effect of dead unwinds without having to compute dataflow twice.
Rollup of 5 pull requests
Successful merges:
- #113115 (we are migrating to askama)
- #114784 (Improve `invalid_reference_casting` lint)
- #114822 (Improve code readability by moving fmt args directly into the string)
- #114878 (rustc book: make more pleasant to search)
- #114899 (Add missing Clone/Debug impls to SMIR Trait related tys)
r? `@ghost`
`@rustbot` modify labels: rollup
Improve code readability by moving fmt args directly into the string
There are some of occurrences where I also transformed `write!(f, "{}", x)` into `f.write_str(x.as_str())`.
r? `@notriddle`
Avoid unnecessary Vec resize.
If `size > 0` current implementation will first create an empty vec and then push an element into it, which will cause a resize that can be easily avoided.
It's obviously not a big deal, but this also gets rid of `mut` local variable.
If `size > 0` current implementation will first create an empty
vec and then push an element into it, which will cause a resize
that can be easily avoided.
It's obviously not a big deal, but this also gets rid of `mut`
local variable.
Fix argument removal suggestion around macros
Fixes#112437.
Fixes#113866.
Helps with #114255.
The issue was that `span.find_ancestor_inside(outer)` could previously return a span with a different expansion context from `outer`.
This happens for example for the built-in macro `panic!`, which expands to another macro call of `panic_2021!` or `panic_2015!`. Because the call site of `panic_20xx!` has not associated source code, its span currently points to the call site of `panic!` instead.
Something similar also happens items that get desugared in AST->HIR lowering. For example, `for` loops get two spans: One "inner" span that has the `.desugaring_kind()` kind set to `DesugaringKind::ForLoop` and one "outer" span that does not. Similar to the macro situation, both of these spans point to the same source code, but have different expansion contexts.
This causes problems, because joining two spans with different expansion contexts will usually[^1] not actually join them together to avoid creating "spaghetti" spans that go from the macro definition to the macro call. For example, in the following snippet `full_span` might not actually contain the `adjusted_start` and `adjusted_end`. This caused the broken suggestion / debug ICE in the linked issues.
```rust
let adjusted_start = start.find_ancestor_inside(shared_ancestor);
let adjusted_end = end.find_ancestor_inside(shared_ancestor);
let full_span = adjusted_start.to(adjusted_end)
```
To fix the issue, this PR introduces a new method, `find_ancestor_inside_same_ctxt`, which combines the functionality of `find_ancestor_inside` and `find_ancestor_in_same_ctxt`: It finds an ancestor span that is contained within the parent *and* has the same syntax context, and is therefore safe to extend. This new method should probably be used everywhere, where the returned span is extended, but for now it is just used for the argument removal suggestion.
Additionally, this PR fixes a second issue where the function call itself is inside a macro but the arguments come from outside the macro. The test is added in the first commit to include stderr diff, so this is best reviewed commit by commit.
[^1]: If one expansion context is the root context and the other is not.
When reporting a heap use-after-free, say where the allocation was allocated and deallocated
This is a partial solution to: https://github.com/rust-lang/miri/issues/2917
Currently in the interpreter, we only have accurate information for where heap allocations are allocated and deallocated (see https://github.com/rust-lang/miri/pull/2940#discussion_r1243559711). So this just implements support for allocations where the information is already available, and the full support will require more interpreter tweaks.
Rollup of 7 pull requests
Successful merges:
- #114721 (Optimizing the rest of bool's Ord implementation)
- #114746 (Don't add associated type bound for non-types)
- #114779 (Add check before suggest removing parens)
- #114859 (Add trait related queries to SMIR's rustc_internal)
- #114861 (fix typo: affect -> effect)
- #114867 ([nit] Fix a comment typo.)
- #114871 (Update the link in the docs of `std::intrinsics`)
r? `@ghost`
`@rustbot` modify labels: rollup
