about summary refs log tree commit diff
path: root/compiler/rustc_mir_transform/src
AgeCommit message (Collapse)AuthorLines
2025-03-10Revert "Use workspace lints for crates in `compiler/` #138084"许杰友 Jieyou Xu (Joe)-0/+1
Revert <https://github.com/rust-lang/rust/pull/138084> to buy time to consider options that avoids breaking downstream usages of cargo on distributed `rustc-src` artifacts, where such cargo invocations fail due to inability to inherit `lints` from workspace root manifest's `workspace.lints` (this is only valid for the source rust-lang/rust workspace, but not really the distributed `rustc-src` artifacts). This breakage was reported in <https://github.com/rust-lang/rust/issues/138304>. This reverts commit 48caf81484b50dca5a5cebb614899a3df81ca898, reversing changes made to c6662879b27f5161e95f39395e3c9513a7b97028.
2025-03-09Rollup merge of #138084 - nnethercote:workspace-lints, r=jieyouxuMatthias Krüger-1/+0
Use workspace lints for crates in `compiler/` This is nicer and hopefully less error prone than specifying lints via bootstrap. r? ``@jieyouxu``
2025-03-08Auto merge of #137502 - compiler-errors:global-asm-aint-mir-body, r=oli-obkbors-0/+4
Don't include global asm in `mir_keys`, fix error body synthesis r? oli-obk Fixes #137470 Fixes #137471 Fixes #137472 Fixes #137473 try-job: test-various try-job: x86_64-apple-2
2025-03-08Remove `#![warn(unreachable_pub)]` from all `compiler/` crates.Nicholas Nethercote-1/+0
(Except for `rustc_codegen_cranelift`.) It's no longer necessary now that `unreachable_pub` is in the workspace lints.
2025-03-07Rollup merge of #137977 - nnethercote:less-kw-Empty-1, r=spastorinoMatthias Krüger-2/+1
Reduce `kw::Empty` usage, part 1 This PR fixes some confusing `kw::Empty` usage, fixing a crash test along the way. r? ```@spastorino```
2025-03-07Rollup merge of #134797 - spastorino:ergonomic-ref-counting-1, r=nikomatsakisMatthias Krüger-1/+1
Ergonomic ref counting This is an experimental first version of ergonomic ref counting. This first version implements most of the RFC but doesn't implement any of the optimizations. This was left for following iterations. RFC: https://github.com/rust-lang/rfcs/pull/3680 Tracking issue: https://github.com/rust-lang/rust/issues/132290 Project goal: https://github.com/rust-lang/rust-project-goals/issues/107 r? ```@nikomatsakis```
2025-03-07Pass `Option<Symbol>` to `def_path_data`/`create_def` methods.Nicholas Nethercote-2/+1
It's clearer than using `kw::Empty` to mean `None`.
2025-03-06Generate the right MIR for by use closuresSantiago Pastorino-1/+1
2025-03-06Factor out check whether an unwind action generates invokeTomasz Miąsko-7/+10
2025-03-06Break critical edges in inline asm before code generationTomasz Miąsko-0/+26
An inline asm terminator defines outputs along its target edges -- a fallthrough target and labeled targets. Code generation implements this by inserting code directly into the target blocks. This approach works only if the target blocks don't have other predecessors. Establish required invariant by extending existing code that breaks critical edges before code generation.
2025-03-06Exclude global_asm from mir_keysMichael Goulet-0/+4
2025-03-06Factor out edge breaking codeTomasz Miąsko-13/+11
2025-03-05Auto merge of #137907 - compiler-errors:inline-fnonce, r=saethlinbors-20/+16
Inline `FnOnce`/`FnMut`/`Fn` shims once again This PR fixes the argument checking for `extern "rust-call"` ABI functions with a spread arg, which do no expect their arguments to be exploded from a tuple like closures do. Secondly, it removes the hack that prevented them from being inlined. This results in more work done by the compiler, but it does end up allowing us to inline functions we didn't before. Fixes #137901
2025-03-05Rollup merge of #138028 - workingjubilee:is-rustic-abi, r=compiler-errors许杰友 Jieyou Xu (Joe)-5/+1
compiler: add `ExternAbi::is_rustic_abi` Various parts of the compiler were hand-rolling this extremely simple check that is nonetheless easy to get wrong as the compiler evolves over time. Discourage them from being so "original" again by replacing it with a single implementation on the type that represents these ABIs. This simplifies a surprising amount of code as a result. Also fixes #132981, an ICE that emerged due to other checks being made stricter.
2025-03-05Rollup merge of #137298 - compiler-errors:mir-wf, r=lcnr许杰友 Jieyou Xu (Joe)-0/+18
Check signature WF when lowering MIR body Alternative to #137233. https://github.com/rust-lang/rust/pull/137233#issuecomment-2667879143 Fixes https://github.com/rust-lang/rust/issues/137186 We do this check in `mir_drops_elaborated_and_const_checked` and not during `mir_promoted` because that may result in borrowck cycles if WF requires looking into an opaque hidden type. This causes some TAIT tests to fail unnecessarily. r? lcnr try-job: test-various
2025-03-04compiler: use `is_rustic_abi` in mir_transformJubilee Young-5/+1
no functional changes.
2025-03-04Remove obsolete comment from DeduceReadOnlyTomasz Miąsko-29/+0
The situation described in the comment does arise in practice now and described panic is long gone.
2025-03-03Inline FnOnce once againMichael Goulet-13/+10
2025-03-03Better reasons for inline failureMichael Goulet-9/+8
2025-03-03Check signature WF when lowering MIR bodyMichael Goulet-0/+18
2025-02-28rename BackendRepr::Vector → SimdVectorRalf Jung-1/+1
2025-02-26Print out destructorMichael Goulet-168/+6
2025-02-24Auto merge of #135726 - jdonszelmann:attr-parsing, r=oli-obkbors-1/+1
New attribute parsing infrastructure Another step in the plan outlined in https://github.com/rust-lang/rust/issues/131229 introduces infrastructure for structured parsers for attributes, as well as converting a couple of complex attributes to have such structured parsers. This PR may prove too large to review. I left some of my own comments to guide it a little. Some general notes: - The first commit is basically standalone. It just preps some mostly unrelated sources for the rest of the PR to work. It might not have enormous merit on its own, but not negative merit either. Could be merged alone, but also doesn't make the review a whole lot easier. (but it's only +274 -209) - The second commit is the one that introduces new infrastructure. It's the important one to review. - The 3rd commit uses the new infrastructure showing how some of the more complex attributes can be parsed using it. Theoretically can be split up, though the parsers in this commit are the ones that really test the new infrastructure and show that it all works. - The 4th commit fixes up rustdoc and clippy. In the previous 2 they didn't compile yet while the compiler does. Separated them out to separate concerns and make the rest more palatable. - The 5th commit blesses some test outputs. Sometimes that's just because a diagnostic happens slightly earlier than before, which I'd say is acceptable. Sometimes a diagnostic is now only emitted once where it would've been twice before (yay! fixed some bugs). One test I actually moved from crashes to fixed, because it simply doesn't crash anymore. That's why this PR Closes #132391. I think most choices I made here are generally reasonable, but let me know if you disagree anywhere. - The 6th commit adds a derive to pretty print attributes - The 7th removes smir apis for attributes, for the time being. The api will at some point be replaced by one based on `rustc_ast_data_structures::AttributeKind` In general, a lot of the additions here are comments. I've found it very important to document new things in the 2nd commit well so other people can start using it. Closes #132391 Closes #136717
2025-02-24Change span field accesses to method callsJana Dönszelmann-1/+1
2025-02-24Rollup merge of #136610 - Jarcho:range_idx, r=NoratriebJacob Pratt-5/+4
Allow `IndexSlice` to be indexed by ranges. This comes with some annoyances as the index type can no longer inferred from indexing expressions. The biggest offender for this is `IndexVec::from_fn_n(|idx| ..., n)` where the index type won't be inferred from the call site or any index expressions inside the closure. My main use case for this is mapping a `Place` to `Range<Idx>` for value tracking where the range represents all the values the place contains.
2025-02-23Rollup merge of #137451 - compiler-errors:synm, r=NoratriebTrevor Gross-1/+1
FIx `sym` -> `syn` typo in tail-expr-drop-order type opt-out The #131326 PR attempts to reduce some false positives for the `tail_expr_drop_order` lint by hard-coding some common ecosystem crate names. Specifically, I believe it attempts to opt out the drop impls from `syn` which only exist as optimizations. However, this was typo'd like "sym", which is a crate that has been [yanked](https://crates.io/crates/sym) (lol). This PR fixes that. cc `@dingxiangfei2009` `@nikomatsakis` -- did I mistake this? Was this meant to be a different crate? `@bors` rollup
2025-02-23The sym crate is not a thingMichael Goulet-1/+1
2025-02-22Greatly simplify lifetime captures in edition 2024Michael Goulet-10/+7
2025-02-22Fix binding mode problemsMichael Goulet-11/+11
2025-02-21Allow SliceIndex to be indexed by ranges.Jason Newcomb-3/+3
2025-02-21Iterate directly on block indices in `rustc_mir_transform`Jason Newcomb-2/+1
2025-02-21Rollup merge of #137305 - nnethercote:rustc_middle-2, r=lcnrMatthias Krüger-5/+5
Tweaks in and around `rustc_middle` A bunch of tiny improvements I found while working on bigger things. r? ```@lcnr```
2025-02-21Rename `ClearCrossCrate::assert_crate_local`.Nicholas Nethercote-5/+5
As `unwrap_crate_local`, because it follows exactly the standard form of an `unwrap` function.
2025-02-20Remove `BackendRepr::Uninhabited`, replaced with an `uninhabited: bool` ↵Zachary S-1/+4
field in `LayoutData`. Also update comments that refered to BackendRepr::Uninhabited.
2025-02-19Rollup merge of #137251 - Zalathar:holes-visitor, r=jieyouxuMatthias Krüger-25/+26
coverage: Get hole spans from nested items without fully visiting them This is a small simplification to the code that collects the spans of nested items within a function, so that those spans can be treated as “holes” to be avoided by the current function's coverage mappings. The old code was using `nested_filter::All` to ensure that the visitor would see nested items. But we don't need the actual items themselves; we just need their spans, which we can obtain via a custom implementation of `visit_nested_item`. This avoids the more expansive queries required by `nested_filter::All`.
2025-02-19Auto merge of #136539 - matthewjasper:late-normalize-errors, r=compiler-errorsbors-2/+15
Emit dropck normalization errors in borrowck Borrowck generally assumes that any queries it runs for type checking will succeed, thinking that HIR typeck will have errored first if there was a problem. However as of #98641, dropck isn't run on HIR, so there's no direct guarantee that it doesn't error. While a type being well-formed might be expected to ensure that its fields are well-formed, this is not the case for types containing a type projection: ```rust pub trait AuthUser { type Id; } pub trait AuthnBackend { type User: AuthUser; } pub struct AuthSession<Backend: AuthnBackend> { data: Option<<<Backend as AuthnBackend>::User as AuthUser>::Id>, } pub trait Authz: Sized { type AuthnBackend: AuthnBackend<User = Self>; } pub fn run_query<User: Authz>(auth: AuthSession<User::AuthnBackend>) {} // ^ No User: AuthUser bound is required or inferred. ``` While improvements to trait solving might fix this in the future, for now we go for a pragmatic solution of emitting an error from borrowck (by rerunning dropck outside of a query) and making drop elaboration check if an error has been emitted previously before panicking for a failed normalization. Closes #103899 Closes #135039 r? `@compiler-errors` (feel free to re-assign)
2025-02-19coverage: Make `HolesVisitor::visit_hole_span` a regular methodZalathar-18/+18
2025-02-19coverage: Get hole spans from nested items without fully visiting themZalathar-8/+9
It turns out that this visitor doesn't actually need `nested_filter::All` to handle nested items; it just needs to override `visit_nested_item` and look up the item's span.
2025-02-19Rollup merge of #137213 - nnethercote:rm-rustc_middle-mir-tcx, r=compiler-errorsMatthias Krüger-1/+1
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`
2025-02-19Remove `rustc_middle::mir::tcx` module.Nicholas Nethercote-1/+1
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.
2025-02-18Rollup merge of #137203 - nnethercote:improve-MIR-modification, ↵Matthias Krüger-136/+126
r=compiler-errors Improve MIR modification A few commits that simplify code that manipulates MIR bodies. r? `@tmiasko`
2025-02-18Inline and replace `Statement::replace_nop`.Nicholas Nethercote-3/+5
It has a single call site, and doesn't seem worth having as an API function.
2025-02-18Inline and remove `BasicBlockData::retain_statements`.Nicholas Nethercote-5/+6
It has a single call site, and the code is clearer this way.
2025-02-18Improve `MirPatch` documentation and naming.Nicholas Nethercote-16/+41
It's currently lacking comments. This commit adds some, which is useful because there are some methods with non-obvious behaviour. The commit also renames two things: - `patch_map` becomes `term_patch_map`, because it's only about terminators. - `is_patched` becomes `is_term_patched`, for the same reason. (I would guess that originally `MirPatch` only handled terminators, and then over time it expanded to allow other modifications, but these names weren't updated.)
2025-02-18Use `MirPatch` in `EnumSizeOpt`.Nicholas Nethercote-112/+74
Instead of `expand_statements`. This makes the code shorter and consistent with other MIR transform passes. The tests require updating because there is a slight change in MIR output: - the old code replaced the original statement with twelve new statements. - the new code inserts converts the original statement to a `nop` and then insert twelve new statements in front of it. I.e. we now end up with an extra `nop`, which doesn't matter at all.
2025-02-18Move methods from `Map` to `TyCtxt`, part 2.Nicholas Nethercote-8/+8
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.
2025-02-17Handle normalization failures in drop elaborationMatthew Jasper-2/+15
Drop elaboration looks at fields of a type, which may error when we try to normalize them. Borrowck will have detected this if HIR typeck didn't, but we don't delete the MIR body for errors in borrowck so still have to handle this happening in drop elaboration by checking whether an error has been emitted.
2025-02-17Rollup merge of #136466 - nnethercote:start-removing-Map, r=cjgillotMatthias Krüger-6/+5
Start removing `rustc_middle::hir::map::Map` `rustc_middle::hir::map::Map` is now just a low-value wrapper around `TyCtxt`. This PR starts removing it. r? `@cjgillot`
2025-02-17Overhaul the `intravisit::Map` trait.Nicholas Nethercote-5/+4
First of all, note that `Map` has three different relevant meanings. - The `intravisit::Map` trait. - The `map::Map` struct. - The `NestedFilter::Map` associated type. The `intravisit::Map` trait is impl'd twice. - For `!`, where the methods are all unreachable. - For `map::Map`, which gets HIR stuff from the `TyCtxt`. As part of getting rid of `map::Map`, this commit changes `impl intravisit::Map for map::Map` to `impl intravisit::Map for TyCtxt`. It's fairly straightforward except various things are renamed, because the existing names would no longer have made sense. - `trait intravisit::Map` becomes `trait intravisit::HirTyCtxt`, so named because it gets some HIR stuff from a `TyCtxt`. - `NestedFilter::Map` assoc type becomes `NestedFilter::MaybeTyCtxt`, because it's always `!` or `TyCtxt`. - `Visitor::nested_visit_map` becomes `Visitor::maybe_tcx`. I deliberately made the new trait and associated type names different to avoid the old `type Map: Map` situation, which I found confusing. We now have `type MaybeTyCtxt: HirTyCtxt`.
2025-02-17Move some `Map` methods onto `TyCtxt`.Nicholas Nethercote-1/+1
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`.