The first approximation of name resolution #22
Conversation
The first attempt to write something useful about the name resolution. As the TODO section says, his is not finished thing, but it might hopefully be useful to someone already.
yes that is ok
yep, why wait? |
| them. | ||
|
|
||
| In other words, when the code talks about namespaces, it doesn't mean the module | ||
| hierarchy, it's types vs. values vs. macros. |
There was a problem hiding this comment.
Seems good. I think we want to avoid trying to teach too must Rust here, but some bits are no doubt unavoidable. This note strikes a good balance.
src/name-resolution.md
Outdated
| shadowed by anything else). The transition to outer rib may also change the | ||
| rules what names are usable ‒ if there are nested functions (not closures), the | ||
| inner one can't access parameters and local bindings of the outer one, even | ||
| though they should be visible by ordinary scoping rules. |
There was a problem hiding this comment.
I think here it'd be helpful to have an example -- just show some rust code and the set of ribs in scope at some particular point. No need to dive into fancy features, just a generic impl + function will have plenty of ribs to get the point across.
There was a problem hiding this comment.
I'm not sure how helpful or readable that example is, but I think it could help a bit.
src/name-resolution.md
Outdated
| hierarchy. | ||
|
|
||
| There are some exceptions to this. Items are bit tricky, because they can be | ||
| used even before encountered ‒ therefore every bock needs to be first scanned |
|
|
||
| This is a result of the first pass of learning the code. It is definitely | ||
| incomplete and not detailed enough. It also might be inaccurate in places. | ||
| Still, it probably provides useful first guidepost to what happens in there. |
There was a problem hiding this comment.
This seems great. It's already hitting on some of the tensions of this book, of course -- I would love it if we had a way to link into the code, so that e.g. we could show some code that is setting up ribs, and then be notified if we got an error later. But I think it's good as is.
|
ping @vorner -- think you'll have a chance to address feedback here? |
I hope to get to it in few hours today. I didn't have the time during the week. |
|
Added as a fixup, so the changes are easier to review. |
|
@vorner seems good, did you want to squash? |
| modules. | ||
| * Introducing a let binding ‒ this can shadow another binding with the same | ||
| name. | ||
| * Macro expansion border ‒ to cope with macro hygiene. |
There was a problem hiding this comment.
I'm guessing pattern matching and globals too?
There was a problem hiding this comment.
Also, do generics ( named lifetimes(impl<T>) andimpl<'a>) follow this rule?
EDIT: sorry, I should have read the rest of the chapter first
The first attempt to write something useful about the name resolution.
As the TODO section says, his is not finished thing, but it might
hopefully be useful to someone already.
This is part of #16, but this wouldn't be complete enough to call that one done. My next plan is to do a more thorough read through the code than just a fast scan, annotating the undocumented items with comments (what is the convention, is it OK to put doc comments on private items?) and then try to improve this.
Apart from the possible usefulness for others, I already wrote this incomplete thing to make sure I don't forget what I've already learned ‒ I don't know when I'll have the time to do another pass (which will take longer than the first scan).
Few questions:
use of unstable library feature 'rustc_private': mainly needed for compiler internals (see issue #27812)from libfmt_macros. I compile with nightly, so it is a bit strange.