what's the difference between
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.
iterate_impl_items takes a
not sure if that makes sense (:
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
resolve_path_fp is for the module-level resolution: it should resolve the path up to the first associated item.
Everything else should be handled separately, by the type checker.
I can make
String::new() resolve to
String, but that's not too useful. I'm not sure what happens to the last segment
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
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.
cc @Florian Diebold
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
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
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)
PerNs be an enum? I'm not sure what
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
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.
Maybe I should watch that rust-analyzer video
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]
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).
, 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.
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?):
The key person here is @pnkfelix , but, if @nikomatsakis were available, that'd be cool!
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
sure, that sounds fine with me. Hopefully niko can make it
Hey, @pnkfelix let's discuss name resolution stuff this week? I guess we can do this in async-way in this thread
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
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