Name resolution for lifetimes.
Name resolution for lifetimes follows much simpler rules than the full resolve. For example, lifetime names are never exported or used between functions, and they operate in a purely top-down way. Therefore, we break lifetime name resolution into a separate pass.
Maps the id of each lifetime reference to the lifetime decl that it corresponds to.
Detects late-bound lifetimes and inserts them into
Item that contains the given
Scan the bounds and where-clauses on parameters to extract bounds
of the form
T:'a so as to determine the
for each type parameter.
ResolveLifetimes map that contains data for an entire
You should not read the result of this query directly, but rather use
any owner (structs, traits, trait methods, etc.), does lifetime resolution.
There are two important things this does.
First, we have to resolve lifetimes for
Item that contains this owner, because that’s the largest “scope”
where we can have relevant lifetimes.
Second, if we are asking for lifetimes in a trait definition, we use
resolve_lifetimes, which does not descend into the trait items and does not emit diagnostics.
This allows us to avoid cycles. Importantly, if we ask for lifetimes for lifetimes that have an owner
other than the trait itself (like the trait methods or associated types), then we just use the regular
resolve_lifetimes, but does not resolve lifetimes for trait items.
Also does not generate any diagnostics.
In traits, there is an implicit
Self type parameter which comes before the generics.
We have to account for this when computing the index of the other generic parameters.
This function returns whether there is such an implicit parameter defined on the given item.