"name resolution"

[nikomatsakis]

We should be talking about the librustc_resolve crate works here. Some topics of interest:

• Handling scopes within the crate
  • What is a rib? (The first approximation of name resolution #22)
  • Where do ribs get added / removed, what happens if I need to introduce a binder? (The first approximation of name resolution #22)
  • How does pub use and stuff like that work
  • Globs and ambiguity
• How do names from external crates fit in?

[vorner]

Hello.

Could I have a try with this one? Few notes:

• I don't know much about the compiler. But there's the name of the relevant crate in the instructions and I usually prefer learning on my own, so I'll try reading it through and if I have problems understanding, I'd ask for some help later on.
• I can't really (yet) get an estimate on when I'd have something to show, with both not really knowing much about the subject and working on it during evenings after a day job.

[nikomatsakis]

@vorner sounds good to me! One of the things I've been wrestling with, as an aside, is just how much detail this guide should go into. I don't think it should replace "in-code" comments -- that is, we don't want the material to become outdated very regularly. We'll have to feel our way.

To that end, I was thinking that perhaps a good place to start would be to dive into the code and try to add comments explaining how it works. This will of course be kind of "bottom up" -- at some point then we should be able to decide what of that material should go into guide, which should go into the code itself.

Anyway, let me know how things are going. I'll try to check in from time to time.

[vorner]

My idea was to do the comments in code (if I find places where the code isn't self-documenting and find them missing) and then try to write a high level picture with very little details. I guess it'll need some more iteration later on, and details can always be added.

[nikomatsakis]

@vorner sounds perfect

[mark-i-m]

Ping @vorner ?

Did you wish to continue iterating on this chapter?

[mark-i-m]

Ping @vorner ?

[vorner]

Did you wish to continue iterating on this chapter?

Sorry, I was busy and missed the previous ping :-|.

Yes, I still want to have a second go through the code, put comments on there and polish the text in the chapter and possibly add some more details.

But if I'm taking too long, I'd definitely understand if someone else wants to take it over (though it seems there's plenty of other work available).

[mark-i-m]

No worries!

I just was making sure you were still interested :)

[demurgos]

Thank you for your work on this guide, it's really helpful.
I am currently trying to understand how name resolution works with cycles between types so it would be great if this was expanded. I think it relates to the following parts:

There are some exceptions to this. Items are bit tricky, because they can be used even before encountered ‒ therefore every block needs to be first scanned for items to fill in its Rib.

Other, even more problematic ones, are imports which need recursive fixed-point resolution and macros, that need to be resolved and expanded before the rest of the code can be processed.

[mark-i-m]

Did you ever find out anything about this?

[vorner]

If it is question aimed at me, then no. Whatever I discovered through the code has been put into the text.

[mark-i-m]

Thanks @vorner :) I actually meant the question for @demurgos

[varkor]

It says ribs were explained as part of #21, but that doesn't seem to be the case. I can't see them mentioned anywhere, including the glossary.

[mark-i-m]

@varkor Sorry, should be #22. Updated above. Also, rib should probably be added the glossary.

IIRC each rib corresponds to a scope or namespace. For example, there is a rib for global names, a rib for items declared in module foo, a rib for names in function foo::bar, and so on...