about summary refs log tree commit diff
path: root/compiler/rustc_borrowck/src
AgeCommit message (Collapse)AuthorLines
2025-10-02Auto merge of #147138 - jackh726:split-canonical-bound, r=lcnrbors-1/+1
Split Bound index into Canonical and Bound See [#t-types/trait-system-refactor > perf `async-closures/post-mono-higher-ranked-hang.rs`](https://rust-lang.zulipchat.com/#narrow/channel/364551-t-types.2Ftrait-system-refactor/topic/perf.20.60async-closures.2Fpost-mono-higher-ranked-hang.2Ers.60/with/541535613) for context Things compile and tests pass, but not sure if this actually solves the perf issue (edit: it does). Opening up this to do a perf (and maybe crater) run. r? lcnr
2025-10-02Auto merge of #147055 - beepster4096:subtype_is_not_a_projection, r=lcnrbors-21/+6
Turn ProjectionElem::Subtype into CastKind::Subtype I noticed that drop elaboration can't, in general, handle `ProjectionElem::SubType`. It creates a disjoint move path that overlaps with other move paths. (`Subslice` does too, and I'm working on a different PR to make that special case less fragile.) If its skipped and treated as the same move path as its parent then `MovePath.place` has multiple possible projections. (It would probably make sense to remove all `Subtype` projections for the canonical place but it doesn't make sense to have this special case for a problem that doesn't actually occur in real MIR.) The only reason this doesn't break is that `Subtype` is always the sole projection of the local its applied to. For the same reason, it works fine as a `CastKind` so I figured that makes more sense than documenting and validating this hidden invariant. cc rust-lang/rust#112651, rust-lang/rust#133258 r? Icnr (bc you've been the main person dealing with `Subtype` it looks like)
2025-09-30Split Bound into Canonical and Boundjackh726-1/+1
2025-09-30Rollup merge of #147109 - BoxyUwU:rename_concrete_opaques, r=lcnrStuart Cook-62/+44
Rename various "concrete opaque type" things to say "hidden type" r? lcnr I've found "concrete opaque type" terminology to be somewhat confusing as in conversation and when explaining opaque type stuff to people I always just talk about things in terms of hidden types. Also the hidden types of opaques are very much not *concrete* in the same sense that a type without any generic parameters is concrete which is an unfortunate overlap in terminology. I've tried to update comments to also stop referring to things as concrete opaque types but this is mostly best effort as it difficult to find all such cases amongst the massive amounts of uses of "concrete" or "hidden" across the whole compiler.
2025-09-29more renameBoxy Uwu-21/+29
2025-09-28Point at multiple outlives requirements instead of just the first oneEsteban Küber-5/+8
``` error[E0716]: temporary value dropped while borrowed --> $DIR/multiple-sources-for-outlives-requirement.rs:5:38 | LL | fn foo<'b>() { | -- lifetime `'b` defined here LL | outlives_indir::<'_, 'b, _>(&mut 1u32); | ---------------------------------^^^^-- temporary value is freed at the end of this statement | | | | | creates a temporary value which is freed while still in use | argument requires that borrow lasts for `'b` | note: requirements that the value outlives `'b` introduced here --> $DIR/multiple-sources-for-outlives-requirement.rs:1:23 | LL | fn outlives_indir<'a: 'b, 'b, T: 'a>(_x: T) {} | ^^ ^^ ```
2025-09-28Address review commentEsteban Küber-10/+14
2025-09-28reword noteEsteban Küber-1/+1
2025-09-28Point at lifetime requirement origin in more casesEsteban Küber-17/+15
2025-09-28Point at fn bound that introduced lifetime obligationEsteban Küber-1/+10
``` error[E0597]: `c` does not live long enough --> $DIR/without-precise-captures-we-are-powerless.rs:19:20 | LL | fn simple<'a>(x: &'a i32) { | -- lifetime `'a` defined here ... LL | let c = async move || { println!("{}", *x); }; | - binding `c` declared here LL | outlives::<'a>(c()); | ---------------^--- | | | | | borrowed value does not live long enough | argument requires that `c` is borrowed for `'a` LL | outlives::<'a>(call_once(c)); LL | } | - `c` dropped here while still borrowed | note: requirement that `c` is borrowed for `'a` introduced here --> $DIR/without-precise-captures-we-are-powerless.rs:7:33 | LL | fn outlives<'a>(_: impl Sized + 'a) {} | ^^ ``` When encountering a `ConstraintCategory::Predicate` in a funtion call, point at the `Span` for that `Predicate` to explain where the lifetime obligation originates from.
2025-09-27Rename various "concrete opaque type" terminology to say "hidden type"Boxy Uwu-69/+43
2025-09-26ProjectionElem::Subtype -> CastKind::Subtypebeepster4096-21/+6
2025-09-24Rollup merge of #146711 - lcnr:fix-placeholder-ice, r=lqdMatthias Krüger-3/+17
fix 2 borrowck issues fixes https://github.com/rust-lang/rust/issues/146467 cc ``@amandasystems`` our understanding here is as follows: region constraints from computing implied bounds gets `ConstraintCategory::Internal`. If there's a higher-ranked subtyping errors while computing implied bounds we then ended up with only `ConstraintCategory::Internal` and `ConstraintCategory::OutlivesUnnameablePlaceholder(_)` constraints. The path was something like - `'placeholderU2: 'placeholderU1` (`Internal`) - `'placeholderU1: 'static` (`OutlivesUnnameablePlaceholder('placeholderU2)`) It's generally somewhat subtle here as ideally relating placeholders doesn't introduce `'static` constraints. Relating the placeholders themselves will always error regardless, cc https://github.com/rust-lang/rust/pull/142623. --- separately fixes https://github.com/rust-lang/rust/pull/145925#issuecomment-3303733357 by updating the location for deferred closure requirements inside of promoteds. I am not updating their category as doing so is 1) effort and 2) imo actually undesirable :thinking: see the comments in `TypeChecker::check_promoted` cc ``@lqd`` r? lqd
2025-09-24fix wordinglcnr-1/+1
Co-authored-by: Rémy Rakic <remy.rakic+github@gmail.com>
2025-09-18Rollup merge of #146717 - amandasystems:remove-placeholder-hack, r=lcnrMatthias Krüger-12/+18
Clean up universe evaluation during type test evaluation The logic was, as the removed comments suggest, hackish and meant to implement previous logic that was factored out. The new logic does exactly what the comments say, and is much less surprising. I'm afraid we may want r? `@lcnr` for this one too. I am sorry, but at least it should be easier to review.
2025-09-18Rollup merge of #146597 - modhanami:add-struct-tail-recursion-limit-span, ↵Matthias Krüger-6/+10
r=oli-obk Add span for struct tail recursion limit error Fixes rust-lang/rust#135629 Changes 1. Add span to RecursionLimitReached 2. Add ObligationCause parameter to struct_tail_raw 4. Update call sites to pass nearby ObligationCause or create one 5. Update affected .stderr
2025-09-18Clean up universe evaluation during type test evaluationAmanda Stjerna-12/+18
The logic was, as the removed comments suggest, hackish and meant to implement previous logic that was factored out. The new logic does exactly what the comments say, and is much less surprising.
2025-09-18internal constraints are better than placeholder outliveslcnr-3/+4
2025-09-18fix location for nested bodies in promotedslcnr-0/+13
2025-09-18Rollup merge of #146664 - fmease:clean-up-dyn, r=jdonszelmannStuart Cook-8/+6
Clean up `ty::Dynamic` 1. As a follow-up to PR rust-lang/rust#143036, remove `DynKind` entirely. 2. Inside HIR ty lowering, consolidate modules `dyn_compatibility` and `lint` into `dyn_trait` * `dyn_compatibility` wasn't about dyn compatibility itself, it's about lowering trait object types * `lint` contained dyn-Trait-specific diagnostics+lints only
2025-09-17Remove `DynKind`León Orell Valerian Liehr-8/+6
2025-09-16Remove Rvalue::Len.Camille Gillot-11/+3
2025-09-16Add span for struct tail recursion limit errorTawan Muadmuenwai-6/+10
2025-09-12Introduce trait_item_ofCameron Steffen-1/+1
2025-09-09erase_regions to erase_and_anonymize_regionsBoxy-5/+7
2025-09-06identity uses are ok, even if there are no defining useslcnr-1/+10
2025-09-01Auto merge of #145925 - lcnr:revealing-use-closures-2, r=BoxyUwUbors-201/+456
`-Znext-solver`: support non-defining uses in closures Cleaned up version of rust-lang/rust#139587, finishing the implementation of https://github.com/rust-lang/types-team/issues/129. This does not affect stable. The reasoning for why this is the case is subtle however. ## What does it do We split `do_mir_borrowck` into `borrowck_collect_region_constraints` and `borrowck_check_region_constraints`, where `borrowck_collect_region_constraints` returns an enormous `CollectRegionConstraintsResult` struct which contains all the relevant data to actually handle opaque type uses and to check the region constraints later on. `query mir_borrowck` now simply calls `BorrowCheckRootCtxt::do_mir_borrowck` which starts by iterating over all nested bodies of the current function - visiting nested bodies before their parents - and computing their `CollectRegionConstraintsResult`. After we've collected all constraints it's time to actually compute the concrete types for the opaques defined by this function. With this PR we now compute the concrete types of opaques for each body before using them to check the non-defining uses of any of them. After we've computed the concrete types by using all bodies, we use `apply_computed_concrete_opaque_types` for each body to constrain non-defining uses, before finally finishing with `borrowck_check_region_constraints`. We always visit nested bodies before their parents when doing this. ## `ClosureRegionRequirements` As we only call `borrowck_collect_region_constraints` for nested bodies before type checking the parent, we can't simply use the final `ClosureRegionRequirements` of the nested body during MIR type check. We instead track that we need to apply these requirements in `deferred_closure_requirements`. We now manually apply the final closure requirements to each body after handling opaque types. This works, except that we may need the region constraints of nested bodies to successfully define an opaque type in the parent. This is handled by using a new `fn compute_closure_requirements_modulo_opaques` which duplicates region checking - while ignoring any errors - before we've added the constraints from `apply_computed_concrete_opaque_types`. This is necessary for a lot of async tests, as pretty much the entire function is inside of an async block while the opaque type gets defined in the parent. As an performance optimization we only use `fn compute_closure_requirements_modulo_opaques` in case the nested body actually depends on any opaque types. Otherwise we eagerly call `borrowck_check_region_constraints` and apply the final closure region requirements right away. ## Impact on stable code Handling the opaque type uses in the parent function now only uses the closure requirements *modulo opaques*, while it previously also considered member constraints from nested bodies. `External` regions are never valid choice regions. Also, member constraints will never constrain a member region if it is required to be outlived by an external region, as that fails the upper-bound check. https://github.com/rust-lang/rust/blob/564ee219127b796d56f74767366fd359758b97de/compiler/rustc_borrowck/src/region_infer/opaque_types/member_constraints.rs#L90-L96 Member constraints therefore never add constraints for external regions :> r? `@BoxyUwU`
2025-09-01use defining uses of all bodies to constrain non-defining useslcnr-201/+456
support non-defining uses in closures
2025-09-01Introduce `MirDumper` and `MirWriter`.Nicholas Nethercote-74/+48
MIR dumping is a mess. There are lots of functions and entry points, e.g. `dump_mir`, `dump_mir_with_options`, `dump_polonius_mir`, `dump_mir_to_writer`. Also, it's crucial that `create_dump_file` is never called without `dump_enabled` first being checked, but there is no mechanism for ensuring this and it's hard to tell if it is satisfied on all paths. (`dump_enabled` is checked twice on some paths, however!) This commit introduces `MirWriter`, which controls the MIR writing, and encapsulates the `extra_data` closure and `options`. Two existing functions are now methods of this type. It sets reasonable defaults, allowing the removal of many `|_, _| Ok(())` closures. The commit also introduces `MirDumper`, which is layered on top of `MirWriter`, and which manages the creation of the dump files, encapsulating pass names, disambiguators, etc. Four existing functions are now methods of this type. - `MirDumper::new` will only succeed if dumps are enabled, and will return `None` otherwise, which makes it impossible to dump when you shouldn't. - It also sets reasonable defaults for various things like disambiguators, which means you no longer need to specify them in many cases. When they do need to be specified, it's now done via setter methods. - It avoids some repetition. E.g. `dump_nll_mir` previously specifed the pass name `"nll"` four times and the disambiguator `&0` three times; now it specifies them just once, to put them in the `MirDumper`. - For Polonius, the `extra_data` closure can now be specified earlier, which avoids having to pass some arguments through some functions.
2025-09-01Use trait object references for closures.Nicholas Nethercote-3/+3
The dynamic dispatch cost doesn't matter for MIR dumping, which is perf-insensitive. And it's necessary for the next commit, which will store some `extra_data` closures in a struct.
2025-08-27Auto merge of #140737 - amandasystems:revised-constraint-search, r=lcnrbors-202/+247
Region inference: Use outlives-static constraints in constraint search Revise the extra `r: 'static` constraints added upon universe issues to add an explanation, and use that explanation during constraint blame search. This greatly simplifies the region inference logic, which now does not need to reverse-engineer the event that caused a region to outlive `'static`. This cosmetically changes the output of two UI tests. I blessed them i separate commits with separate motivations, but that can of course be squashed as desired. We probably want that. The PR was extracted out of rust-lang/rust#130227 and consists of one-third of its functional payload. r? lcnr
2025-08-25Auto merge of #145711 - lcnr:non-defining-uses-hir-typeck, r=BoxyUwUbors-10/+9
Support non-defining uses in HIR typeck This changes the impl of `NormalizesTo` for opaque types to be structural during HIR typeck. The previous impl equated region variables of the opaque type key with existing entries which can result in spurious leak check errors and also results in mismatches with MIR borrowck, theoretically causing ICE. The approach is very similar to rust-lang/rust#145244 in MIR typeck: - we collect all uses of opaque types during HIR typeck - before writeback, we search for *defining uses* - the opaque type key has fully universal generic args modulo regions - the hidden type has no infer vars - we use these defining uses to compute the concrete type for the opaque and map it to the definition site - we use this concrete type to check the type of all uses of opaques during HIR typeck. This also constrains infer vars in non-defining uses Fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/135, fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/49. r? `@BoxyUwU`
2025-08-25change non-defining use error messagelcnr-1/+0
2025-08-25support non-defining uses in HIR typecklcnr-10/+10
2025-08-25Rollup merge of #145620 - compiler-errors:fake-dyn-to-dyn, r=lcnrStuart Cook-62/+74
Account for impossible bounds making seemingly unsatisfyable dyn-to-dyn casts Fixes https://github.com/rust-lang/rust/issues/141806 When we have an impossible where clause like `dyn Trait<u8>: Sized`, this may make a dyn-to-dyn cast like `dyn Trait<()> -> dyn trait<u8>` to successfully type check as if it were a wide-to-thin ptr cast (discarding metadata): https://github.com/rust-lang/rust/blob/16ad385579cebb6f7d53367c552661b6b51a4a02/compiler/rustc_hir_typeck/src/cast.rs#L862-L865 In borrowck, we are expecting that the only meaningful dyn-to-dyn cast to be a metadata-preserving wide-to-wide ptr cast, which requires that the principals of the dyn pointers are equal. Borrowck additionally assumes that these principals have already been proven equal *modulo regions*, and we thus ICE since `Trait<u8>` and `Trait<()>` do not unify: https://github.com/rust-lang/rust/blob/16ad385579cebb6f7d53367c552661b6b51a4a02/compiler/rustc_borrowck/src/type_check/mod.rs#L1481-L1524 This PR fixes this ICE by checking whether the RHS of the cast is considered to be Sized in the environment of the MIR typeck, and if so then skipping over this dyn->dyn principal compatibility check. r? `@lcnr` perhaps?
2025-08-23Simplify SCC annotations somewhatAmanda Stjerna-24/+8
2025-08-23NitsMichael Goulet-71/+72
2025-08-23Account for impossible bounds making seemingly unsatisfyable dyn-to-dyn castsMichael Goulet-11/+22
2025-08-22change HIR typeck unification handling approachlcnr-45/+51
2025-08-22Region inference: Use outlives-static constraints in constraint searchAmanda Stjerna-188/+249
Revise the extra `r: 'static` constraints added upon universe issues to add an explanation, and use that explanation during constraint blame search. This greatly simplifies the region inference logic, which now does not need to reverse-engineer the event that caused a region to outlive 'static.
2025-08-21Auto merge of #145701 - jhpratt:rollup-a0kg33p, r=jhprattbors-1/+1
Rollup of 19 pull requests Successful merges: - rust-lang/rust#143383 (stabilize `const_array_each_ref`) - rust-lang/rust#144758 ([Doc] Add links to the various collections) - rust-lang/rust#144915 (Defer tail call ret ty equality to check_tail_calls) - rust-lang/rust#145256 (Add new `--test-codegen-backend` bootstrap option) - rust-lang/rust#145297 (fix(debuginfo): handle false positives in overflow check) - rust-lang/rust#145390 (Shorten some dependency chains in the compiler) - rust-lang/rust#145415 (std_detect: RISC-V: implement implication to "C") - rust-lang/rust#145525 (stdlib: Replace typedef -> type alias in doc comment) - rust-lang/rust#145590 (Prevent impossible combinations in `ast::ModKind`.) - rust-lang/rust#145593 (UnsafePinned::raw_get: sync signature with get) - rust-lang/rust#145621 (Fix some doc typos) - rust-lang/rust#145627 (Unconditionally-const supertraits are considered not dyn compatible) - rust-lang/rust#145642 (Do not use effective_visibilities query for Adt types of a local trait while proving a where-clause) - rust-lang/rust#145650 (Fix JS search scripts path) - rust-lang/rust#145654 (Download CI GCC into the correct directory) - rust-lang/rust#145662 (Enforce correct number of arguments for `"x86-interrupt"` functions) - rust-lang/rust#145673 (Add flock support for cygwin) - rust-lang/rust#145674 (Enable triagebot `[review-changes-since]` feature) - rust-lang/rust#145678 (Fix typo in docstring) r? `@ghost` `@rustbot` modify labels: rollup
2025-08-20diagnostics :3lcnr-19/+43
2025-08-20handle opaque types before region inferencelcnr-1128/+957
2025-08-20`region_infer::opaque_types` to folderlcnr-0/+0
2025-08-20`fully_perform_op_raw` out of `TypeChecker`lcnr-31/+75
2025-08-19Defer tail call ret ty equality to check_tail_callsMichael Goulet-1/+1
2025-08-19Rollup merge of #142079 - lcnr:opaque-types-universes, r=BoxyUwU许杰友 Jieyou Xu (Joe)-2/+7
nll-relate: improve hr opaque types support This should currently not be user-facing outside of diagnostics as even if we successfully relate the opaque types, we don't support opaque types with non-param arguments and also require all member regions to be equal to the arguments or `'static`. This means there's no way to end up with a placeholder in the hidden type. r? types
2025-08-19Rollup merge of #145041 - lcnr:borrowck-limitations-error, r=BoxyUwUStuart Cook-13/+72
rework GAT borrowck limitation error The old one depends on the `ConstraintCategory` of the constraint which meant we did not emit this note if we had to prove the higher ranked trait bound due to e.g. normalization. This made it annoying brittle and caused MIR borrowck errors to be order dependent, fixes the issue in https://github.com/rust-lang/rust/pull/140737#discussion_r2259592651. r? types cc ```@amandasystems```
2025-08-18comment style changesDeadbeef-35/+34
2025-08-18nll-relate: improve hr opaque types supportlcnr-2/+7