Uh oh!
There was an error while loading. Please reload this page.
Implement tool_attributes feature (RFC 2103) - #47773
Conversation
topecongiro
commented
Jan 26, 2018
Hmm. Should I add the section to the unstable book after this PR is merged, or am I missing something? I followed the instruction in https://forge.rust-lang.org/feature-guide.html. |
kennytm
commented
Jan 26, 2018
@topecongiro The problem is that unstable book file should be written in hyphenated lower case. Try to rename it as |
topecongiro
commented
Jan 26, 2018
@kennytm Thank you! |
There was a problem hiding this comment.
Contents of ast::Attribute and ast::MetaItem are the same thing by definition, but in the compiler they diverged significantly in recent months.
An attribute is a "macro invocation" that consists of a Path and a TokenStream, MetaItem should have the same structure and they should share code, ideally.
I'd rather do this refactoring instead of adding temporary hacks like Vec<Name>, preferably in a separate PR.
(The attribute/meta-item Path goes through usual path resolution procedure, and that's where resolution of the "tool module" rustfmt or clippy should be added as well, ideally.)
nrc
left a comment
There was a problem hiding this comment.
This looks fine to me, but I think someone more active in compiler work should sign off too.
There was a problem hiding this comment.
Could we use a Path here, rather than Vec<Name>?
There was a problem hiding this comment.
In fact I wonder if we could use Path instead of MetaItemName and always treat attributes as paths rather than names (we have to do this for macro attributes anyway)
nrc
commented
Jan 29, 2018
@petrochenkov@nrc Thank you for you reviews! So I am going to replace EDIT: I actually kept the tool name checking in feature_gate.rs. |
54f59e1 to
b6a9355CompareThere was a problem hiding this comment.
Looks like existing print_path can be used instead of introducing this new function.
There was a problem hiding this comment.
print_path is not a method of PrintState trait, so I am not sure how to exploit it. Should I write like self.writer().word(&path_to_string(path))?
petrochenkov
commented
Jan 30, 2018
|
There was a problem hiding this comment.
This looks like an imitation of parse_path, but I don't know how make the normal version and tokenstream version reuse the same code.
Could you leave a FIXME comment here?
There was a problem hiding this comment.
Where does this special back-compat support of Word meta items happen now?
There was a problem hiding this comment.
Oh, wait parse_path_allowing_meta is reintroduced in the next commit.
There was a problem hiding this comment.
Could you use the last segment instead?
In #[a::b::c]a and b are modules (possibly "tool modules") in which the attribute c is defined, and the last segment c is the attribute itself.
There was a problem hiding this comment.
This solution is 100% technical debt, but I guess it can work while everything is unstable, and we go into this branch only if previous ways to resolve the attribute failed.
I described the proper solution in rust-lang/rfcs#2103 (comment).
TLDR: a::b::c in #[a::b::c(...)] should be resolved as a usual path in macro namespace and therefore rustfmt and clippy should be added into the language prelude as special modules (primitive types u8, u16, etc work in very similar way).
I don't suggest to implement this now though.
There was a problem hiding this comment.
I don't suggest to implement this now though.
But I suggest to implement this eventually, if you plan to continue working on macros/attributes and name resolution in rustc.
There was a problem hiding this comment.
Typo "unkown" -> "unknown"
topecongiro
commented
Feb 3, 2018
@petrochenkov Thank you for your reviews and I am sorry for the late reply. I hope that I can update this PR today... |
petrochenkov
commented
Feb 4, 2018
@bors r+ |
bors
commented
Feb 4, 2018
📌 Commit 30214c9 has been approved by |
bors
commented
Feb 4, 2018
⌛ Testing commit 30214c90d560ddc3b6e83992f34afb340dd43d5e with merge cac046403a27dd42eb53ef8b9c94801592a12b5d... |
bors
commented
Feb 4, 2018
💔 Test failed - status-travis |
And fix some typos
topecongiro
commented
Feb 12, 2018
Rebased against master. I have a problem reproducing the above failures locally... running |
petrochenkov
commented
Feb 12, 2018
@topecongiro It is possible that this is an expected pretty-printer failure, then you can disable the test with |
topecongiro
commented
Feb 12, 2018
@petrochenkov Thank you for your advice, I could reproduce this locally. I cannot tell whether this is an expected pretty-printer failure or not. I looked at the original PR that added this test (#40346). It looks like now arbitrary tokens could appear as arguments to procedural macros. So I guess that this PR is trying to parse random tokens inside procedural macros as some valid paths when it shouldn't? Again, I am not sure, though. |
| self.parse_sess.span_diagnostic, | ||
| attr.span, | ||
| E0693, | ||
| "An unknown tool name found in scoped attributes: `{}`.", |
There was a problem hiding this comment.
Nit: error messages conventionally start with a lower-case letter.
(Same in the feature gate message below.)
petrochenkov
commented
Feb 12, 2018
@topecongiro I don't quite see where is the difference in name resolution comes from. Please make sure the logic for single-segment attribute paths is identical to what it was before. For example, |
emilyalbini
commented
Feb 19, 2018
@topecongiro can you fix that failing test so the PR can be merged? |
bors
commented
Feb 25, 2018
☔ The latest upstream changes (presumably #48520) made this pull request unmergeable. Please resolve the merge conflicts. |
shepmaster
commented
Mar 2, 2018
Thank you for your hard work, @topecongiro ! However, we haven't heard from you in a few weeks, so I'm going to close this PR for now to keep the queue tidy. Please feel free to reopen this when you have a chance to fix the merge conflicts and the failing test. |
This PR implements a
tool_attributesfeature. If this implementaion is acceptable, I am going to create a similar PR that implementstool_lints.This PR only adds
rustfmtandclippyto known tool name list. The list resides in libsyntax/attr.rs.cc #44690.
r? @nrc