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"(?)

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)

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

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


		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

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!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

fallible-algebra commented Jul 10, 2026 •

edited

Loading

BoxyUwU left a comment •

edited by rustbot

Loading

BoxyUwU Jul 29, 2026 •

edited

Loading