Remove `rustc_middle::mir::tcx` module.
This is a really weird module. For example, what does `tcx` in `rustc_middle::mir::tcx::PlaceTy` mean? The answer is "not much".
The top-level module comment says:
> Methods for the various MIR types. These are intended for use after
> building is complete.
Awfully broad for a module that has a handful of impl blocks for some MIR types, none of which really relates to `TyCtxt`. `git blame` indicates the comment is ancient, from 2015, and made sense then.
This module is now vestigial. This commit removes it and moves all the code within into `rustc_middle::mir::statement`. Some specifics:
- `Place`, `PlaceRef`, `Rvalue`, `Operand`, `BorrowKind`: they all have `impl` blocks in both the `tcx` and `statement` modules. The commit merges the former into the latter.
- `BinOp`, `UnOp`: they only have `impl` blocks in `tcx`. The commit moves these into `statement`.
- `PlaceTy`, `RvalueInitializationState`: they are defined in `tcx`. This commit moves them into `statement` *and* makes them available in `mir::*`, like many other MIR types.
r? `@tmandry`
This is a really weird module. For example, what does `tcx` in
`rustc_middle::mir::tcx::PlaceTy` mean? The answer is "not much".
The top-level module comment says:
> Methods for the various MIR types. These are intended for use after
> building is complete.
Awfully broad for a module that has a handful of impl blocks for some
MIR types, none of which really relates to `TyCtxt`. `git blame`
indicates the comment is ancient, from 2015, and made sense then.
This module is now vestigial. This commit removes it and moves all the
code within into `rustc_middle::mir::statement`. Some specifics:
- `Place`, `PlaceRef`, `Rvalue`, `Operand`, `BorrowKind`: they all have `impl`
blocks in both the `tcx` and `statement` modules. The commit merges
the former into the latter.
- `BinOp`, `UnOp`: they only have `impl` blocks in `tcx`. The commit
moves these into `statement`.
- `PlaceTy`, `RvalueInitializationState`: they are defined in `tcx`.
This commit moves them into `statement` *and* makes them available in
`mir::*`, like many other MIR types.
Continuing the work started in #136466.
Every method gains a `hir_` prefix, though for the ones that already
have a `par_` or `try_par_` prefix I added the `hir_` after that.
Pattern Migration 2024: clean up and comment
This follows up on #136577 by moving the pattern migration logic to its own module, removing a bit of unnecessary complexity, and adding comments. Since there's quite a bit of pattern migration logic now (and potentially more in #136496), I think it makes sense to keep it separate from THIR construction, at least as much as is convenient.
r? ``@Nadrieril``
Overhaul `rustc_middle::limits`
In particular, to make `pattern_complexity` work more like other limits, which then enables some other simplifications.
r? ``@Nadrieril``
The end goal is to eliminate `Map` altogether.
I added a `hir_` prefix to all of them, that seemed simplest. The
exceptions are `module_items` which became `hir_module_free_items` because
there was already a `hir_module_items`, and `items` which became
`hir_free_items` for consistency with `hir_module_free_items`.
It's similar to the other limits, e.g. obtained via `get_limit`. So it
makes sense to handle it consistently with the other limits. We now use
`Limit`/`usize` in most places instead of `Option<usize>`, so we use
`Limit::new(usize::MAX)`/`usize::MAX` to emulate how `None` used to work.
The commit also adds `Limit::unlimited`.
valtree performance tuning
Summary: This PR makes type checking of code with many type-level constants faster.
After https://github.com/rust-lang/rust/pull/136180 was merged, we observed a small perf regression (https://github.com/rust-lang/rust/pull/136318#issuecomment-2635562821). This happened because that PR introduced additional copies in the fast reject code path for consts, which is very hot for certain crates: 6c1d960d88/compiler/rustc_type_ir/src/fast_reject.rs (L486-L487)
This PR improves the performance again by properly interning the valtrees so that copying and comparing them becomes faster. This will become especially useful with `feature(adt_const_params)`, so the fast reject code doesn't have to do a deep compare of the valtrees.
Note that we can't just compare the interned consts themselves in the fast reject, because sometimes `'static` lifetimes in the type are be replaced with inference variables (due to canonicalization) on one side but not the other.
A less invasive alternative that I considered is simply avoiding copies introduced by https://github.com/rust-lang/rust/pull/136180 and comparing the valtrees it in-place (see commit: 9e91e50ac5 / perf results: https://github.com/rust-lang/rust/pull/136593#issuecomment-2642303245), however that was still measurably slower than interning.
There are some minor regressions in secondary benchmarks: These happen due to changes in memory allocations and seem acceptable to me. The crates that make heavy use of valtrees show no significant changes in memory usage.
The wording unsafe pointer is less common and not mentioned in a lot of
places, instead this is usually called a "raw pointer". For the sake of
uniformity, we rename this method.
This came up during the review of
https://github.com/rust-lang/rust/pull/134424.
Pattern Migration 2024: try to suggest eliding redundant binding modifiers
This is based on #136475. Only the last commit is new.
This is a simpler, more restrictive alternative to #136496, meant to partially address #136047. If a pattern can be migrated to Rust 2024 solely by removing redundant binding modifiers, this will make that suggestion; otherwise, it uses the old suggestion of making the pattern fully explicit.
Relevant tracking issue: #131414
``@rustbot`` label A-diagnostics A-patterns A-edition-2024
r? ``@Nadrieril``
fix tail call checks wrt `#[track_caller]`
Only check the caller + disallow caller having the attribute.
fixes#134336
r? `@compiler-errors`
<sub>apparently there were no tests for `#[track_caller]` before... ooops</sub>
Simplify some code for lowering THIR patterns
I've been playing around with some radically different ways of storing THIR patterns, and while those experiments haven't yet produced a clear win, I have noticed various smaller things in the existing code that can be made a bit nicer.
Some of the more significant changes:
- With a little bit of extra effort (and thoughtful use of Arc), we can completely remove an entire layer of `'pat` lifetimes from the intermediate data structures used for match lowering.
- In several places, lists of THIR patterns were being double-boxed for no apparent reason.
mir_build: Rename `thir::cx::Cx` to `ThirBuildCx` and remove `UserAnnotatedTyHelpers`
A combination of two loosely-related tweaks that would otherwise conflict with each other:
- `Cx` is a pretty unhelpful type name, especially when jumping between THIR-building and MIR-building while trying to make changes to THIR data structures.
- The `UserAnnotatedTyHelpers` trait doesn't appear to provide any benefit over a simple helper function, and its `tcx()` method is currently completely unnecessary.
No functional change.
mir_build: Simplify `lower_pattern_range_endpoint`
By accumulating ascriptions and inline-consts in separate vectors, we can streamline some previously-tricky code for dealing with range patterns.
Add a couple of missing `ensure_sufficient_stacks`
r? `@saethlin` I hope you didn't spend time on this already.
(I couldn't sleep, opened `check_tail_calls`, there was a single call where it could happen, might as well fix it)
This PR adds a couple of missing `ensure_sufficient_stack`s:
- one in `check_tail_calls` that prevented the #135709 backport on some targets.
- after that was fixed, the test still didn't pass starting at 4MB, so I also added one in `check_unsafety` and that made it pass.
I didn't add an `rmake` test purposefully limiting the min stack size on `issue-74564-if-expr-stack-overflow.rs`, but we could if we wanted to.
On `apple-aarch64-darwin`, this is enough to make `RUST_MIN_STACK=$((1024*1024*3)) ./x test tests/ui --test-args tests/ui/issues/issue-74564-if-expr-stack-overflow.rs` pass for me locally, and it does stack overflow otherwise.
This aligns the main error message a bit more with the phrasing in the
Edition Guide and provides a bit more information on the labels to
(hopefully!) aid in understanding.
This does mean that we have to resolve the list of arm IDs twice, but it's
unclear whether that even matters, whereas the cleaner signature is a nice
improvement.
