Support non-defining uses in HIR typeck #145711

lcnr · 2025-08-21T11:57:34Z

This changes they impl of NormalizesTo for opaque types to be structural during HIR typeck. It currently equates 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.

TODO

add tests :3
also describe how non-defining uses work :23
track fixed items from -Znext-solver=globally

r? @BoxyUwU

erase regions also anonymizes bound vars, which is undesirable

rustbot · 2025-08-21T11:57:41Z

Some changes occurred to the core trait solver

cc @rust-lang/initiative-trait-system-refactor

BoxyUwU · 2025-08-21T16:09:11Z

compiler/rustc_middle/src/ty/mod.rs

@@ -832,12 +832,12 @@ impl<'tcx> OpaqueHiddenType<'tcx> {
        //
        // We erase regions when doing this during HIR typeck.
        let this = match defining_scope_kind {
-            DefiningScopeKind::HirTypeck => tcx.erase_regions(self),
+            DefiningScopeKind::HirTypeck => fold_regions(tcx, self, |_, _| tcx.lifetimes.re_erased),


comment about why we don't want to anonymize bound vars

BoxyUwU · 2025-08-21T17:00:51Z

compiler/rustc_hir_typeck/src/opaque_types.rs

+                if opaque_type_key.def_id != def_id {
+                    continue;
+                }
+                if let Err(err) = check_opaque_type_parameter_valid(


I think this framing of "check X" with it returning an Err(err) is really confusing now that we have non defining uses. It's not an error to have a non defining use and its also not "invalid" to have weird arguments to opaques, its just a decision about whether its a defining use or not.

rename to opaque_type_has_defining_use_args, NonDefiningUseReason

BoxyUwU · 2025-08-21T17:06:16Z

compiler/rustc_hir_typeck/src/opaque_types.rs

+    ///
+    /// A use during HIR typeck is defining if all non-lifetime arguments are
+    /// unique generic parameters and the hidden type does not reference any
+    /// unconstrained inference variables.


Suggested change

/// unconstrained inference variables.

/// inference variables.

Clarifying unconstrained is just confusing to me. imo in general in the compiler the default assumption is that we are talking about the resolved forms of types.

BoxyUwU · 2025-08-21T17:20:49Z

compiler/rustc_hir_typeck/src/opaque_types.rs

+            let mut non_defining_use = None;
+            let mut unconstrained_hidden_type = None;
+            let mut found_defining_use = false;
+            for &(opaque_type_key, hidden_type) in opaque_types {


i find the structure of this loop + the variables declared ahead of time to be quite confusing but I'm not sure I can articulate what my problem with it is

enum UsageKind { None, NonDefiningUse(...), UnconstrainedHiddenType(..), HasDefiningUse, }

with usage_kind.merge(consider_opaque_type_use(...)): in the loop

add comment why no short circuit, it's only diagnostics :3

instead, actually short circuit and add new cause kind to the relate in apply_uses.

BoxyUwU · 2025-08-21T17:23:58Z

compiler/rustc_hir_typeck/src/opaque_types.rs

+                        )
+                        .emit()
+                } else if let Some((_, hidden_type)) = non_defining_use {
+                    tcx.dcx().span_err(hidden_type.span, "non-defining use in the defining scope")


non defining uses are not errors. this should be "non defining use without a defining use"

just emit "no defining use" + "note, does nothave unique universal generic arguments" or sth

compiler/rustc_hir_typeck/src/opaque_types.rs

BoxyUwU · 2025-08-21T17:41:03Z

compiler/rustc_hir_typeck/src/writeback.rs

+        let fcx_typeck_results = self.fcx.typeck_results.borrow();
+        assert_eq!(fcx_typeck_results.hir_owner, self.typeck_results.hir_owner);
+        for (&def_id, &hidden_type) in &fcx_typeck_results.concrete_opaque_types {
+            assert!(!hidden_type.has_infer());
+            self.typeck_results.concrete_opaque_types.insert(def_id, hidden_type);
+        }


Suggested change

let fcx_typeck_results = self.fcx.typeck_results.borrow();

assert_eq!(fcx_typeck_results.hir_owner, self.typeck_results.hir_owner);

for (&def_id, &hidden_type) in &fcx_typeck_results.concrete_opaque_types {

assert!(!hidden_type.has_infer());

self.typeck_results.concrete_opaque_types.insert(def_id, hidden_type);

}

let fcx_typeck_results = self.fcx.typeck_results.borrow();

assert_eq!(fcx_typeck_results.hir_owner, self.typeck_results.hir_owner);

assert!(fcx_typeck_results.concrete_opaque_types.values().all(|hidden_ty| !hidden_ty.has_infer()))

assert_eq!(self.typeck_results.concrete_opaque_types.len(), 0)

self.typeck_results.concrete_opaque_types = fcx_typeck_results.concrete_opaque_types.clone();

does your code differ in some way from just cloning concrete_opaque_types? more performant because you can do the assertion while "cloning" it? we expect for other parts of write back to insert stuff into opaque type storage for some reason?

ye, mem::take

BoxyUwU · 2025-08-21T17:49:09Z

compiler/rustc_next_trait_solver/src/solve/normalizes_to/opaque_types.rs

                    self.structurally_instantiate_normalizes_to_term(goal, goal.predicate.alias);
                    return self.evaluate_added_goals_and_make_canonical_response(Certainty::Yes);


can you add a comment saying "if we're not in the defining scope treat the alias as rigid" or something, I got tripped up by the let else as usual

compiler/rustc_next_trait_solver/src/solve/normalizes_to/opaque_types.rs

BoxyUwU · 2025-08-21T18:04:23Z

compiler/rustc_next_trait_solver/src/solve/normalizes_to/opaque_types.rs

+                // We structurally normalize the args so that we're able to detect defining uses
+                // later on. It also reduces the amount of duplicate definitions in the
+                // `opaque_type_storage`.


It's not clear to me that "reduces the amount of duplicate definitions in the opaque type storage" is actually a good thing.

This would improve inference as a usage of Opaque<T> and Opaque<<T as Trait>::Self> now share opaque type storage entries. This then means that the exact behaviour of structurally_normalize_ty can affect whether normalization of an opaque results in an infer var or some partially-inferred hidden type from a previous usage.

Like the fact that structurally normalize ty is actually "deeply normalize except for aliases with bound vars" is now something which affects the results of opaque type normalization.

This makes me feel stronger that we should have normalization of opaques to look up all the existing usages and infer a hidden type based off that as it would mitigate this. Having opaque type keys differ in normalization doesn't affect inference if we allow usages to affect eachother's hidden types

add comment

bors · 2025-08-23T06:28:05Z

☔ The latest upstream changes (presumably #145469) made this pull request unmergeable. Please resolve the merge conflicts.

lcnr added 4 commits August 21, 2025 12:45

change HIR typeck unification handling approach

367eb05

comment update

a8f4c7d

fold regions, don't erase

772566b

erase regions also anonymizes bound vars, which is undesirable

support non-defining uses in HIR typeck

a78b9d1

rustbot assigned BoxyUwU Aug 21, 2025

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. WG-trait-system-refactor The Rustc Trait System Refactor Initiative (-Znext-solver) labels Aug 21, 2025

BoxyUwU reviewed Aug 21, 2025

View reviewed changes

BoxyUwU added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 21, 2025

	/// unconstrained inference variables.
	/// inference variables.

		self.structurally_instantiate_normalizes_to_term(goal, goal.predicate.alias);
		return self.evaluate_added_goals_and_make_canonical_response(Certainty::Yes);

Support non-defining uses in HIR typeck #145711

Are you sure you want to change the base?

Support non-defining uses in HIR typeck #145711

Conversation

lcnr commented Aug 21, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

TODO

Uh oh!

rustbot commented Aug 21, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bors commented Aug 23, 2025

Uh oh!

Uh oh!

lcnr commented Aug 21, 2025 •

edited

Loading