-
Notifications
You must be signed in to change notification settings - Fork 565
Add section on expansion-time (early) name resolution #2055
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
Thanks for posting. Lot of good here. The main thing I'd suggest, by way of helping to sharpen this up, would be to try to write a concise example after each claim, in as many cases as that might make sense, that demonstrates that the claim is true (and would not pass if the claim were false). Aside from the intrinsic benefit of having such examples, I think this might help to focus the text on the language-level effects. (It's not surprising, given the good research you've been doing, that some bits of this currently have some "description of the implementation" flavor.) |
yaahc
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
a fair number of comments are also contained inline in the documents
This comment has been minimized.
This comment has been minimized.
|
@ehuss and I are looking at this together on the lang-docs office hours call, and we just wanted to express our appreciation to @petrochenkov for having been so responsive with @yaahc on working out the details here. This is a chapter that we've long wanted to exist, and we're thrilled and appreciative that @yaahc is digging in to shape this up. |
5397d08 to
1bd3afe
Compare
80fd707 to
570bedd
Compare
This comment has been minimized.
This comment has been minimized.
d87f2d8 to
db220a9
Compare
d4d235d to
122378f
Compare
This comment has been minimized.
This comment has been minimized.
src/names/name-resolution.md
Outdated
| ambig!(); // ERROR: `ambig` is ambiguous. | ||
| ``` | ||
|
|
||
| This also applies to imports, so long as the innermost candidate for the invocation of name is from within a macro expansion. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We were puzzling over this sentence and were wondering if you could clarify something.
(The phrase "the invocation of name" seemed out of place here, and we are assuming this should be "the name", since there isn't an invocation here.)
This ambiguities section starts off talking about an ambiguity involving macro invocations and expanded macros. But then this sentence seems to say, "oh and the ambiguity applies to imports, too.". Am I understanding it correctly that the rule here applies to macro invocations and imports? Is there a reason the start of the rule leaves out the "and imports" part?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The "invocation" language came up because of this function and how it refers to the site the name being resolved came from as an invocation regardless of whether it was an import or a macro. I wasn't really sure if this was the more proper term or not, elsewhere in the reference I've used language like "name is used" to the same effect.
I just reread the beginning of this ambiguity section and at least the way I read and meant it it's not talking about this as only applying to macros. Whether or not the invocation is a macro or a use decl there have to be macro expansions involved in order for this lint to trigger. I did my best to make the language generic in the beginning and talk about candidates without specifically saying imports or macro definitions as the sources of those candidate bindings.
122378f to
0408914
Compare
|
This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
0a93b28 to
934f5ad
Compare
Co-authored-by: Vadim Petrochenkov <[email protected]> Co-authored-by: Eric Huss <[email protected]> Co-authored-by: Tshepang Mbambo <[email protected]> Co-authored-by: Travis Cross <[email protected]>
Many earlier passes of revisions have been squashed into the chapter itself. These edits are the final pass.
We're not certain what this rule means; we've run various tests and
could not confirm our interpretation of the rule. E.g. (thanks to
ehuss for this):
```rust
use pm::{WithHelperAttr, helper};
#[derive(WithHelperAttr)]
#[helper]
#[derive(helper)] // ERROR: expected derive macro, found derive helper attribute `helper`
struct S;
```
Interestingly, this works and calls the attribute macro:
```rust
use pm::{WithHelperAttr, helper};
#[derive(WithHelperAttr, helper)]
#[helper]
struct S;
```
So that we can merge the rest, let's remove this rule for now and add
it back in future work.
934f5ad to
ce32028
Compare
|
Thanks @yaahc. Great work here, and great working with you on it. Thanks to @petrochenkov for the critical support. |
currently mostly a skeleton of a draft so we can collaboratively massage it into shape more easily before filling in with proper reference verbiage.
hoping to take a significant chunk out of #568