Dropbox Paper

Loading...

Lazy normalization

Const generics interaction that doesn’t work today

(need an example)

Zulip Topic

Improving the bugs (ICEs and other bad behavior) around higher-ranked regions and normalization

Other reliability? Other classes of bugs

Projection flow today

Top-level functions:

normalize(selcx)

normalize_with_depth

AssociatedTypeNormalizer —

“type folder” that

These invoke:

for associated types:

normalize_projection_type

for constants:

Instance::resolve and then const_eval

normalize_projection_type:

param_env

projection_ty — <P0 as Trait<P1..Pn>>::Item

invokes opt_normalize_projection_type below

if ambiguity results, adds a fresh inference variable ?X to be the “normalized” result

and adds the obligation Normalize(<P0 as Trait<P1..Pn>>::Item → ?X), effectively

opt_normalize_projection_type:

takes a projection P

returns a (normalized) type plus add’l obligations

or returns None in the case of ambiguity (e.g., <?T as Foo>::Bar)

checks cache keyed by the projection P stored in the infcx

cache-key includes the full type (type variables and all)

cycle? “overflow”, this might be something to change around lazy normalization

cache miss —

insert a placeholder into cache key

invoke project_type

replace placeholder with result

cache hit —

includes a result but also sub-obligations

ordinarily, these sub-obligations aren’t needed —

the person who populated cache already proved them

but under some weird edge cases it may be needed to resolve them in order to resolve dependent type variables (see e.g. #43132)

project_type — given <P0 as Trait<P1..Pn>>::Item

assembles candidates from various sources:

param-env

search environment

trait-definition (“implied bounds”)

for a projection like <<A as Foo>::FooT as Bar>::BarT check if trait definition looks like type FooT : Bar<BarT=i32>