HIR "Eager Type Inference" / Expectations dev guide page by fallible-algebra · Pull Request #2924 · rust-lang/rustc-dev-guide

fallible-algebra · 2026-07-10T15:23:33Z

Page on "Eager Type Inference" / Expectations. Currently deep in drafts.

Is eager type inference the right phrase here? How do we need to represent it to the reader?
Answer why the following need to use eager type inference / expectations
- closures (kinda done)
- coercions
- These do not reference expectations in terms of logic, but do pass around an expectations arg for diagnostics.
  - indexes
  - fields
  - methods
Establish if the whole bidirectional type system paper needs mentioning, and how to do that in a way that makes sense to people other than type theory sickos.
- it's the source of "do some more type checking earlier"(?)
Post in the zulip

fallible-algebra · 2026-07-10T15:23:56Z

@BoxyUwU

BoxyUwU · 2026-07-10T17:04:36Z

@fallible-algebra :)

…cally

rustbot · 2026-07-29T07:45:03Z

Thanks for the PR. If you have write access, feel free to merge this PR if it does not need reviews. You can request a review using r? rustc-dev-guide or r? <username>.

BoxyUwU

beep boop

View changes since this review

BoxyUwU · 2026-07-24T11:52:18Z

+
+In reality, we perform it (at least) twice: First, at eager evaluation points, and secondly "at the end" when those constraints have been collected.
+
+`Expectations` are a piece of type inference state we maintain for the cases where we need to eagerly infer the types of expressions rather than leave them to the end. They allow us to "ask questions" of the form "hey, we're expecting this term to have this type, is this true?"


i feel like its more of a we can ask "what are we expecting the type of this expression to be?"

BoxyUwU · 2026-07-29T08:55:52Z

+
+If we didn't do eager type inference we would instead have closures whose types were filled with [inference variables](../appendix/glossary.md#inf-var). 
+
+This would be able to be solved in some situations, but because we do not have Higher-Ranked Inference Variables[^higher-ranked-inference] this would make the higher-ranked bounds for lifetimes that rust can have unusable without more annotation.


the other reason we care about this is that if you have fn(?x) -> ?y as your closure signature then you can't do field accesses/method calls/etc on ?x which is a quite common thing to want to do

I think more generally we want to talk about how inferring higher ranked things is eager, and there are two main places this happens:

inferring higher ranked closure signatures

subtyping of higher ranked types

BoxyUwU · 2026-07-29T08:57:00Z

+
+[Coercions](./coercions.md) can happen in many places. We check to see if a coercion can happen, and if it can we perform the coercion. 
+
+When we successfully find a coercion, we need to eagerly perform type inference/checking on it as future inference will require or benefit from this information to be known ahead of time.


I don't really know what this sentence is saying 🤔 it also feels a bit backwards to me because once we've "successfully found a coercion" then we've already done "eager type inference" because finding a coercion is the thing that cares about the current state of inference :3

BoxyUwU · 2026-07-29T10:33:51Z

+
+When we successfully find a coercion, we need to eagerly perform type inference/checking on it as future inference will require or benefit from this information to be known ahead of time.
+
+### Method calls, Fields, and Indexes.


structuring this as

Closures

Coercions

Other stuff

feels slightly off to me as I feel like it places too much importance on the expectation vs non expectation distinction between cases of eager type inference

I feel like I would prefer just a flat list of all the places that are eager type inference spots

BoxyUwU · 2026-07-29T10:41:55Z

+
+#### Methods
+
+Maybe Not. Maybe just point to [method lookup](./method-lookup.md).


definitely want to talk about methods :3

I think for each item (e.g. coercions, closures, fields, etc) here we want to cover:

Why it is an eager inference spot

How we handle it being an eager inference spot (we would probably talk about "hey we use expectations" here if we do)

Why we handle it the way we do

for methods this is probably:

method lookup is an eager inference spot because we need to look at the type of the receiver to determine what methods exist

we handle this by erroring if there are inference variables which prevent us from figuring out all the methods we might be able to call

we could move this into the trait solver but it'd complicate things quite a lot and hasn't really been necessary to do so (so mostly historical reasons).

BoxyUwU · 2026-07-29T10:42:08Z

+
+? Method calls engage in Coercion and therefore need to engage in Eager Type Inference.
+
+#### Fields?


definitely want to talk about field accesses :3 its mostly the same reasoning as methods

BoxyUwU · 2026-07-29T10:45:14Z

+Eager evaluation of the type of a term (type inference) is required at some specific points to either make later type inference more consistent or (in the case of higher-ranked bounds / Higher Ranked Lifetime bounds) make it even possible.
+
+Eager type inference is when we do type inference earlier than we otherwise would. To do this, we bring in Expectations as an additional piece of context.
+


general structural thing I think it would be nice to talk about like "the ways we can handle places that care about the current inference state" and sort of talk abstractly about:

we can defer it to arbitrary points during type inference (trait solving works like this)

we can eagerly error on inference variables

we can defer it to the end of typeck after everything has been inferred (array repeat expr checks do this)

re: trait solver doing this: Does this behave differently between the current and next trait solver? And is that a relevant thing for me to bring up :p

BoxyUwU · 2026-07-29T10:46:07Z

+
+Eager type inference is when we do type inference earlier than we otherwise would. To do this, we bring in Expectations as an additional piece of context.
+
+### Closures and Higher-Ranked Variables


i kind of want to add trait solving to the list of "eager inference points" in that they're still part of the general "sometimes we do things which cares about the current inference state" its just that "trait" solving is how we handle that correctly instead of jankily

jyn514 · 2026-08-17T08:03:46Z

@BoxyUwU @fallible-algebra 👋 what's the state of this? is it ok to merge as-is and improve in follow-ups?

jyn514 · 2026-08-17T08:03:56Z

(note that CI is failing)

fallible-algebra · 2026-08-17T08:10:08Z

Still working on it, and I'm away until next week.

jyn514 · 2026-08-17T08:13:09Z

No worries at all :) thanks for the update

BoxyUwU · 2026-08-31T12:23:50Z

+// Maybe later?
+?a = Vec<?b>;
+// And later still
+?a = Vec<String>;


in practice we won't ever record a second constraint for an inference variable. instead we'll zonk it and would have Vec<?b> eq Vec<String> which yields a ?b = String constraint

View changes since the review

Straight up

BoxyUwU · 2026-08-31T12:29:46Z

+
+TODO: Stub, relationship to eager inference is not well established.
+
+TODO: Following are stubs, need to determine if these are relevant to bring up.


they are :3

View changes since the review

BoxyUwU · 2026-08-31T12:34:22Z

+Top-level functions, such as the following, have their types fully annotated at their definition site:
+
+```rust
+fn is_even(number: i32) -> bool {
+    number % 2 == 0
+}
+---
+// We don't have to infer this, it's annotated.
+is_even: fn(i32) -> bool
+```
+
+This makes inference at points where they're used relatively easy. We know it's a `fn(i32) -> bool`, so when we give it an `i32` we know the expression is a `bool`.
+
+_Closures_ need to have type inference eagerly applied to them because they are functions that are rarely fully annotated:
+
+```rust
+let closure = |a, b| if a < b {vec![1, 2, 3]} else {vec![5, 6, 7]};
+---
+// Doesn't capture any information so it's a bare function pointer
+// but we still don't know much about it.
+closure: fn(?x, ?y) -> ?z
+```
+
+If we didn't do eager type inference we would instead have closures whose types were filled with [inference variables](../appendix/glossary.md#inf-var) (like the `?x, ?y, ?z` variables above).
+
+Eagerly inferring the type of `closure` here serves a couple of purposes. Firstly, it's a decent heuristic that if we define a closure we'll use it later and having its type be known will mean a less intense inference solve. Having eagerly inferred the type of a closure lets us establish [Expectations](#expectations) that don't have inference variables in them.


vibes off bestie

View changes since the review

BoxyUwU · 2026-08-31T14:26:18Z

+### Constraints
+
+This is the set of constraints that need to be solved. We collect these constraints as we move through the codebase being type checked.
+


Obligations

sometimes we look at the set of current obligations/goals/predicates the trait solver is required to prove.

View changes since the review

fallible-algebra added 3 commits July 6, 2026 10:05

empty file

48b013e

Some expectations writeup

e996b38

Some assertions, mostly blank space

0dbb79a

More sketching

b5dafa7

fallible-algebra added 3 commits July 20, 2026 10:59

Add a bunch of wrong stuff to check later

5a7be9d

Can't keep fussing over this

5e8bfe6

Link to HRIV

8eaa585

fallible-algebra requested a review from BoxyUwU July 24, 2026 10:03

Re-frame around eager type inference rather than expectations specifi…

7c2f098

…cally

fallible-algebra changed the title ~~HIR Expectations dev guide page~~ HIR "Eager Type Inference" / Expectations dev guide page Jul 29, 2026

fallible-algebra marked this pull request as ready for review July 29, 2026 07:45

rustbot added the S-waiting-on-review Status: this PR is waiting for a reviewer to verify its content label Jul 29, 2026

Some rewording

63acfd0

BoxyUwU self-assigned this Jul 29, 2026

BoxyUwU reviewed Jul 29, 2026

View reviewed changes

Pushing for review purposes

40263ec

jyn514 added S-waiting-on-author Status: this PR is waiting for additional action by the OP and removed S-waiting-on-review Status: this PR is waiting for a reviewer to verify its content labels Aug 17, 2026

fallible-algebra added 2 commits August 28, 2026 17:50

Current state of inference structure etc.

a5d0f0d

Major editing pass

855f60c

fallible-algebra requested a review from BoxyUwU August 31, 2026 12:17

rustbot added S-waiting-on-review Status: this PR is waiting for a reviewer to verify its content and removed S-waiting-on-author Status: this PR is waiting for additional action by the OP labels Aug 31, 2026

BoxyUwU reviewed Aug 31, 2026

View reviewed changes


		In reality, we perform it (at least) twice: First, at eager evaluation points, and secondly "at the end" when those constraints have been collected.

		`Expectations` are a piece of type inference state we maintain for the cases where we need to eagerly infer the types of expressions rather than leave them to the end. They allow us to "ask questions" of the form "hey, we're expecting this term to have this type, is this true?"


		If we didn't do eager type inference we would instead have closures whose types were filled with [inference variables](../appendix/glossary.md#inf-var).

		This would be able to be solved in some situations, but because we do not have Higher-Ranked Inference Variables[^higher-ranked-inference] this would make the higher-ranked bounds for lifetimes that rust can have unusable without more annotation.


		[Coercions](./coercions.md) can happen in many places. We check to see if a coercion can happen, and if it can we perform the coercion.

		When we successfully find a coercion, we need to eagerly perform type inference/checking on it as future inference will require or benefit from this information to be known ahead of time.


		When we successfully find a coercion, we need to eagerly perform type inference/checking on it as future inference will require or benefit from this information to be known ahead of time.

		### Method calls, Fields, and Indexes.


		#### Methods

		Maybe Not. Maybe just point to [method lookup](./method-lookup.md).


		? Method calls engage in Coercion and therefore need to engage in Eager Type Inference.

		#### Fields?

		Eager evaluation of the type of a term (type inference) is required at some specific points to either make later type inference more consistent or (in the case of higher-ranked bounds / Higher Ranked Lifetime bounds) make it even possible.

		Eager type inference is when we do type inference earlier than we otherwise would. To do this, we bring in Expectations as an additional piece of context.


		Eager type inference is when we do type inference earlier than we otherwise would. To do this, we bring in Expectations as an additional piece of context.

		### Closures and Higher-Ranked Variables


		TODO: Stub, relationship to eager inference is not well established.

		TODO: Following are stubs, need to determine if these are relevant to bring up.

		### Constraints

		This is the set of constraints that need to be solved. We collect these constraints as we move through the codebase being type checked.

Uh oh!

Conversation

fallible-algebra commented Jul 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

fallible-algebra commented Jul 10, 2026

Uh oh!

BoxyUwU commented Jul 10, 2026

Uh oh!

rustbot commented Jul 29, 2026

Uh oh!

BoxyUwU left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

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!

BoxyUwU Jul 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

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!

jyn514 commented Aug 17, 2026

Uh oh!

jyn514 commented Aug 17, 2026

Uh oh!

fallible-algebra commented Aug 17, 2026

Uh oh!

jyn514 commented Aug 17, 2026

Uh oh!

BoxyUwU Aug 31, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

BoxyUwU Aug 31, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

BoxyUwU Aug 31, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

BoxyUwU Aug 31, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Obligations

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

fallible-algebra commented Jul 10, 2026 •

edited

Loading

BoxyUwU left a comment •

edited by rustbot

Loading

BoxyUwU Jul 29, 2026 •

edited

Loading

BoxyUwU Aug 31, 2026 •

edited by rustbot

Loading

BoxyUwU Aug 31, 2026 •

edited by rustbot

Loading

BoxyUwU Aug 31, 2026 •

edited by rustbot

Loading

BoxyUwU Aug 31, 2026 •

edited by rustbot

Loading