Minor fixes to $crate behavior
#1816
Conversation
rustbot
added
the
S-waiting-on-review
|
This looks correct to me. |
There was a problem hiding this comment.
Thanks!
I noticed there were quite a few changes to $crate behavior in rust-lang/rust#37213 in 1.14.
I'm slightly uneasy with this because I don't know what is going to happen in the future with RFC 3243 where a crate may end up being a path (foo::bar). I suppose since it will be opaque it's probably not a big deal, but still feels a little weird.
I'm not super happy with how $crate is defined, because it is a bit scattered (in paths.md, macro.decl.meta.dollar-crate, and macro.decl.hygiene.crate). For example, a naive reading could make one think that they could pass $crate into an ident from outside a macro definition, but that is not the case. Only the text in paths.md makes that really clear that it can only be passed in from a transcriber. Anyway, maybe for another day.
The description of the behavior of passing
$crateto a proc-macro is missing, this PR adds one.Similarly the behavior of
identmatching$crateisn't captured. Every other fragment specifier which matches$crategoes throughPathIdentSegmentwhich does contain$crate, but neitherIDENTIFIER_OR_KEYWORDnorRAW_IDENTIFIERcan (or should) match against$crate. Introducing a new definition just to capture this behavior seems like overkill, especially since it would only be used once, so adding an inline or-clause seems like the cleanest solution.