coverage: Extract hole spans from HIR instead of MIR
This makes it possible to treat more kinds of nested item/code as holes, instead of being restricted to closures.
(It also potentially opens up the possibility of using HIR holes to modify branch or MC/DC spans, though we currently don't actually do this.)
Thus, this new implementation treats the following as holes:
- Closures (as before, including `async` and coroutines)
- All nested items
- Inline `const` (because why not)
This gives more accurate coverage reports, because lines occupied by holes don't show the execution count from the enclosing function.
Fixes#126626.
Due to the way the paths initial_rustc and initial_cargo were
constructed before this commit, they mixed \ and / for path separators
and they omitted the .exe suffix.
This worked fine up until now, as Windows is capable of handling the
mixed path separators and the Command::new API adds the ".exe" suffix if
missing from the executable.
This resulted in paths that didn't actually exist on disk though, due to
the missing .exe suffix. This commit fixes that by adding the .exe
suffix to initial_rustc and initial_cargo when --build is Windows.
Make `push_outlives_components` into a `TypeVisitor`
This involves removing the `visited: &mut SsoHashSet<GenericArg<'tcx>>` that is being passed around the `VerifyBoundCx`. The fact that we were using it when decomposing different type tests seems sketchy, so I don't think, though it may technically result in us registering more redundant outlives components 🤷
I did end up deleting some of the comments that referred back to RFC 1214 during this refactor. I can add them back if you think they were useful.
r? lcnr
Rollup of 10 pull requests
Successful merges:
- #126841 ([`macro_metavar_expr_concat`] Add support for literals)
- #126881 (Make `NEVER_TYPE_FALLBACK_FLOWING_INTO_UNSAFE` a deny-by-default lint in edition 2024)
- #126921 (Give VaList its own home)
- #127367 (Run alloc sync tests)
- #127431 (Use field ident spans directly instead of the full field span in diagnostics on local fields)
- #127437 (Uplift trait ref is knowable into `rustc_next_trait_solver`)
- #127439 (Uplift elaboration into `rustc_type_ir`)
- #127451 (Improve `run-make/output-type-permutations` code and improve `filename_not_in_denylist` API)
- #127452 (Fix intrinsic const parameter counting with `effects`)
- #127459 (rustdoc-json: add type/trait alias tests)
r? `@ghost`
`@rustbot` modify labels: rollup
Rollup of 10 pull requests
Successful merges:
- #126841 ([`macro_metavar_expr_concat`] Add support for literals)
- #126881 (Make `NEVER_TYPE_FALLBACK_FLOWING_INTO_UNSAFE` a deny-by-default lint in edition 2024)
- #126921 (Give VaList its own home)
- #127367 (Run alloc sync tests)
- #127431 (Use field ident spans directly instead of the full field span in diagnostics on local fields)
- #127437 (Uplift trait ref is knowable into `rustc_next_trait_solver`)
- #127439 (Uplift elaboration into `rustc_type_ir`)
- #127451 (Improve `run-make/output-type-permutations` code and improve `filename_not_in_denylist` API)
- #127452 (Fix intrinsic const parameter counting with `effects`)
- #127459 (rustdoc-json: add type/trait alias tests)
r? `@ghost`
`@rustbot` modify labels: rollup
Uplift elaboration into `rustc_type_ir`
Allows us to deduplicate and consolidate elaboration (including these stupid elaboration duplicate fns i added for pretty printing like 3 years ago) so I'm pretty hyped about this change :3
r? lcnr
Use field ident spans directly instead of the full field span in diagnostics on local fields
This improves diagnostics and avoids having to store the `DefId`s of fields
Run alloc sync tests
I was browsing the code and this struck me as weird. We're not running some doc tests because, the comment says, Windows builders deadlock. That should absolutely not happen, at least with our current implementation. And if it does happen I'd like to know.
Just to be sure though I'll do some try builds.
try-job: x86_64-msvc
try-job: i686-msvc
try-job: i686-mingw
try-job: x86_64-mingw
Make `NEVER_TYPE_FALLBACK_FLOWING_INTO_UNSAFE` a deny-by-default lint in edition 2024
I don't actually really care about this, but ``@traviscross`` asked me to do this, because lang team briefly discussed this before.
(TC here:)
Specifically, our original FCPed plan included this step:
- Add a lint against fallback affecting a generic that is passed to an `unsafe` function.
- Perhaps make this lint `deny-by-default` or a hard error in Rust 2024.
That is, we had left as an open question strengthening this in Rust 2024, and had marked it as an open question on the tracking issue. We're nominating here to address the open question. (Closing the remaining open question helps us to fully mark this off for Rust 2024.)
r? ``@compiler-errors``
Tracking:
- https://github.com/rust-lang/rust/issues/123748
[`macro_metavar_expr_concat`] Add support for literals
Adds support for things like `${concat($variable, 123)}` or `${concat("hello", "_world")}` .
cc #124225
Support tail calls in mir via `TerminatorKind::TailCall`
This is one of the interesting bits in tail call implementation — MIR support.
This adds a new `TerminatorKind` which represents a tail call:
```rust
TailCall {
func: Operand<'tcx>,
args: Vec<Operand<'tcx>>,
fn_span: Span,
},
```
*Structurally* this is very similar to a normal `Call` but is missing a few fields:
- `destination` — tail calls don't write to destination, instead they pass caller's destination to the callee (such that eventual `return` will write to the caller of the function that used tail call)
- `target` — similarly to `destination` tail calls pass the caller's return address to the callee, so there is nothing to do
- `unwind` — I _think_ this is applicable too, although it's a bit confusing
- `call_source` — `become` forbids operators and is not created as a lowering of something else; tail calls always come from HIR (at least for now)
It might be helpful to read the interpreter implementation to understand what `TailCall` means exactly, although I've tried documenting it too.
-----
There are a few `FIXME`-questions still left, ideally we'd be able to answer them during review ':)
-----
r? `@oli-obk`
cc `@scottmcm` `@DrMeepster` `@JakobDegen`
Support tail calls in mir via `TerminatorKind::TailCall`
This is one of the interesting bits in tail call implementation — MIR support.
This adds a new `TerminatorKind` which represents a tail call:
```rust
TailCall {
func: Operand<'tcx>,
args: Vec<Operand<'tcx>>,
fn_span: Span,
},
```
*Structurally* this is very similar to a normal `Call` but is missing a few fields:
- `destination` — tail calls don't write to destination, instead they pass caller's destination to the callee (such that eventual `return` will write to the caller of the function that used tail call)
- `target` — similarly to `destination` tail calls pass the caller's return address to the callee, so there is nothing to do
- `unwind` — I _think_ this is applicable too, although it's a bit confusing
- `call_source` — `become` forbids operators and is not created as a lowering of something else; tail calls always come from HIR (at least for now)
It might be helpful to read the interpreter implementation to understand what `TailCall` means exactly, although I've tried documenting it too.
-----
There are a few `FIXME`-questions still left, ideally we'd be able to answer them during review ':)
-----
r? `@oli-obk`
cc `@scottmcm` `@DrMeepster` `@JakobDegen`
Cache hir_owner_nodes in ParentHirIterator.
Lint level computation may traverse deep HIR trees using that iterator. This calls `hir_owner_nodes` many times for the same HIR owner, which is wasterful.
This PR caches the value to allow a more efficient iteration scheme.
r? ghost for perf
Rework `init_numbered_fields`
Two behaviour changes:
* Not linting in macros
* Not linting when side effects might be reordered
changelog: `init_numbered_fields`: Don't suggest reordering side effects.
Make `can_eq` process obligations (almost) everywhere
Move `can_eq` to an extension trait on `InferCtxt` in `rustc_trait_selection`, and change it so that it processes obligations. This should strengthen it to be more accurate in some cases, but is most important for the new trait solver which delays relating aliases to `AliasRelate` goals. Without this, we always basically just return true when passing aliases to `can_eq`, which can lead to weird errors, for example #127149.
I'm not actually certain if we should *have* `can_eq` be called on the good path. In cases where we need `can_eq`, we probably should just be using a regular probe.
Fixes#127149
r? lcnr
