-
Notifications
You must be signed in to change notification settings - Fork 24
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Add documentation and make matchers more flexible
- Loading branch information
Showing
1 changed file
with
21 additions
and
5 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
2d9479a
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.
@mystor Out of curiosity, why did you change
#[$attrs:meta]
to#[$($attrs:tt)*]
? Shouldn't it work withmeta
?2d9479a
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.
Ha, well this one is kinda funny.
Attributes can technically take the format of any tokens within a
#[...]
wrapper, rather than specifically something looking like a "Meta Item", which meant that, for a while, it was more correct to match attributes in the manner I wrote it than using$:meta
(see rust-lang/rust#49629 for context). I was originally writing the change this way to try to be compatible with these more general attributes.However, apparently the definition of a valid custom attribute was restricted more in rust-lang/rust#50120, and the
$:meta
matcher was upgraded to support this new syntax in rust-lang/rust#63674. This means that the$:meta
matcher is still fully compatible, and could be used here. I was not aware of rust-lang/rust#63674 at the time, however, and changed it to try to be safe.I'll probably not back this change out, as it's harmless, but I probably wouldn't make it again after looking up the bug to explain the reasoning to you :-).