Stream: t-compiler/wg-rls-2.0

Topic: name resolution


Laurențiu Nicola (Feb 14 2019 at 13:52, on Zulip):

what's the difference between HirDatabase and PersistentHirDatabase?

I'm asking because I wanted to into resolution for associated items, and I'm not sure how to implement it. I can handle ModuleDef::Struct here, but I'm not sure how to reach the item.

Laurențiu Nicola (Feb 14 2019 at 13:54, on Zulip):

my iterate_impl_items takes a HirDatabase

Laurențiu Nicola (Feb 14 2019 at 14:00, on Zulip):

not sure if that makes sense (:

matklad (Feb 14 2019 at 14:22, on Zulip):

PersistentHirDatabase (to be renamed to DefsDatabase maybe?) is for parts of the IDE where we want incrementallity.

HirDatabase is for stuff where we want to be lazy, but don't need to be incremental.

Roughly speaking, everything about types should go to HirDatabase, because it should be ok to re-typecheck a function for completion, everything about macro resolution and modules should go to PersistentHirDatabase

matklad (Feb 14 2019 at 14:23, on Zulip):

resolve_path_fp is for the module-level resolution: it should resolve the path up to the first associated item.

matklad (Feb 14 2019 at 14:24, on Zulip):

Everything else should be handled separately, by the type checker.

Laurențiu Nicola (Feb 14 2019 at 14:24, on Zulip):

I can make String::new() resolve to String, but that's not too useful. I'm not sure what happens to the last segment

matklad (Feb 14 2019 at 14:25, on Zulip):

I think associated item resolution should be handled somewhere aroud https://github.com/rust-analyzer/rust-analyzer/blob/b85c189500a47f3c5f7690250611b06e08616c9a/crates/ra_hir/src/ty.rs#L1107-L1132

matklad (Feb 14 2019 at 14:27, on Zulip):

Ie, for String::new the resolver should say "I've resolved String Def, but I don't know what new is" , and the typechecker should look at the type of the String and find the associated method.

matklad (Feb 14 2019 at 14:27, on Zulip):

cc @Florian Diebold

Florian Diebold (Feb 14 2019 at 18:55, on Zulip):

Yes... The first step would be to make the resolver actually return partial resolutions (i.e. what did the part that could be resolved resolve to, and what segments still remain), and then we can start handling that in ty.rs

Florian Diebold (Feb 14 2019 at 18:58, on Zulip):

so I think for now there would be additional handling after https://github.com/rust-analyzer/rust-analyzer/blob/b85c189500a47f3c5f7690250611b06e08616c9a/crates/ra_hir/src/ty.rs#L1107 for that case

Laurențiu Nicola (Feb 14 2019 at 19:12, on Zulip):

The first step would be to make the resolver actually return partial resolutions (i.e. what did the part that could be resolved resolve to, and what segments still remain)

Should PerNs be an enum? I'm not sure what types and values are.

Florian Diebold (Feb 14 2019 at 19:16, on Zulip):

They're the different namespaces. A name may resolve to different definitions depending on whether you're looking for a type or a value.
I think one possible representation would be (PerNs<Resolution>, &[PathSegment]), although then callers need to make sure to check whether the path fully resolved; or an enum with PartiallyResolved(PerNs<Resolution>, &[PathSegment]), FullyResolved(PerNs<Resolution>)... not sure

Laurențiu Nicola (Feb 14 2019 at 19:17, on Zulip):

I suppose that makes sense. And methods should be... values, I guess? But it wouldn't matter in my case, because the resolution would stop at the parent struct.

Laurențiu Nicola (Feb 14 2019 at 19:18, on Zulip):

Maybe I should watch that rust-analyzer video

eulerdisk (Feb 15 2019 at 15:25, on Zulip):

Hi guys, I just skimmed over name resolution. From what I see resolving use imports inside functions/blocks is not implemented, right? Are there any plans for that?
[Maybe I can try to do it myself, if there are no blockers]

Florian Diebold (Feb 15 2019 at 15:44, on Zulip):

Yes it's not implemented yet. There are plans in the sense of "we need to implement this sometime", but no one has started working on it as far as I know ;)
I don't think there are concrete blockers, but it's kind of complicated -- basically any block that contains items is its own anonymous module, which we need to include in the fixpoint import resolution. Anonymous modules inherit the scope from their parent module (as opposed to named modules, which don't).

matklad (Feb 16 2019 at 09:47, on Zulip):

, which we need to include in the fixpoint import resolution.

Probably not literary include: I think macros declared inside of functions, even in modules, cant escape to the outer scope, so in theory we should be able to resolve each item's block independently. That is, we could run a separate fixed-point iteration per function.

matklad (Apr 16 2019 at 08:10, on Zulip):

We hadn't had a meeting for a while, and we really should move forward with nameresolution librarification. So, let's discuss it (probably on Zulip?):

https://doodle.com/poll/i9mi98urqry6mxnr

cc @WG-rls2.0

The key person here is @pnkfelix , but, if @nikomatsakis were available, that'd be cool!

matklad (Apr 17 2019 at 05:22, on Zulip):

Heh, not a lot of participants on the poll :)

@pnkfelix let's schedule this for tomorrow than, the same time as today's meeting about RLS 1/2

pnkfelix (Apr 17 2019 at 10:18, on Zulip):

sure, that sounds fine with me. Hopefully niko can make it

matklad (May 07 2019 at 09:22, on Zulip):

Hey, @pnkfelix let's discuss name resolution stuff this week? I guess we can do this in async-way in this thread

pnkfelix (May 07 2019 at 11:09, on Zulip):

sure; I don't have much to report yet. I'm trying to tie off an incremental compilation bug before I switch over to this

matklad (May 07 2019 at 11:40, on Zulip):

Cool: fixing that incremental bug will surely have a positive impact on rust-analyzer development velocity :D

We still need to get to name resolution at some point: our macro and trait story is maturing fast, so nameres could become a blocker soon-ish

Last update: Nov 12 2019 at 15:50UTC