@@ -341,6 +341,34 @@ pub fn provide(providers: &mut ty::query::Providers) {
341
341
342
342
/// Like `resolve_lifetimes`, but does not resolve lifetimes for trait items.
343
343
/// Also does not generate any diagnostics.
344
+ ///
345
+ /// This is ultimately a subset of the `resolve_lifetimes` work. It effectively
346
+ /// resolves lifetimes only within the trait "header" -- that is, the trait
347
+ /// and supertrait list. In contrast, `resolve_lifetimes` resolves all the
348
+ /// lifetimes within the trait and its items. There is room to refactor this,
349
+ /// for example to resolve lifetimes for each trait item in separate queries,
350
+ /// but it's convenient to do the entire trait at once because the lifetimes
351
+ /// from the trait definition are in scope within the trait items as well.
352
+ ///
353
+ /// The reason for this separate call is to resolve what would otherwise
354
+ /// be a cycle. Consider this example:
355
+ ///
356
+ /// ```rust
357
+ /// trait Base<'a> {
358
+ /// type BaseItem;
359
+ /// }
360
+ /// trait Sub<'b>: for<'a> Base<'a> {
361
+ /// type SubItem: Sub<BaseItem = &'b u32>;
362
+ /// }
363
+ /// ```
364
+ ///
365
+ /// When we resolve `Sub` and all its items, we also have to resolve `Sub<BaseItem = &'b u32>`.
366
+ /// To figure out the index of `'b`, we have to know about the supertraits
367
+ /// of `Sub` so that we can determine that the `for<'a>` will be in scope.
368
+ /// (This is because we -- currently at least -- flatten all the late-bound
369
+ /// lifetimes into a single binder.) This requires us to resolve the
370
+ /// *trait definition* of `Sub`; basically just enough lifetime information
371
+ /// to look at the supertraits.
344
372
#[ tracing:: instrument( level = "debug" , skip( tcx) ) ]
345
373
fn resolve_lifetimes_trait_definition (
346
374
tcx : TyCtxt < ' _ > ,
0 commit comments