Lazy normalization
  • Const generics interaction that doesn’t work today
  • (need an example)
  • 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>