Stream: t-compiler/rust-analyzer

Topic: ResolvePathResult

Jonas Schievink [he/him] (Jan 21 2021 at 19:42, on Zulip):

We have this struct:

pub(super) struct ResolvePathResult {
    pub(super) resolved_def: PerNs,
    pub(super) segment_index: Option<usize>,
    pub(super) reached_fixedpoint: ReachedFixedPoint,
    pub(super) krate: Option<CrateId>,

...and I'm wondering what the fields other than resolved_def mean exactly. The different namespaces in resolved_def could come from different crates, so having only one krate field seems insufficient, and basically all the remaining fields also seem like they would only make sense for each individual namespace, not the whole result. What am I missing here?

Florian Diebold (Jan 21 2021 at 21:30, on Zulip):

reached_fixedpoint already takes into account all the namespaces, I think -- we've only reached a fixpoint if all namespaces can't change. segment_index is also for all namespaces because you don't resolve the path in each namespace separately -- all the intermediate results are only in the types namespace anyway

Florian Diebold (Jan 21 2021 at 21:33, on Zulip):

as for krate... I don't think it's necessarily the crate that the defs originally come from

Florian Diebold (Jan 21 2021 at 21:35, on Zulip):

I think the only use for it is to detect that if we have an import from another crate, it'll always already be fully resolved . So it doesn't really matter that it's inaccurate

Florian Diebold (Jan 21 2021 at 21:35, on Zulip):

maybe it could be refactored to just use reached_fixedpoint though?

Florian Diebold (Jan 21 2021 at 21:36, on Zulip):

I guess I'd try seeing what happens if we don't do that check

Jonas Schievink [he/him] (Jan 21 2021 at 22:04, on Zulip):

I see, that makes sense

Last update: Jul 26 2021 at 13:30UTC