-
Notifications
You must be signed in to change notification settings - Fork 13.3k
$crate incorrectly substituted in attribute macro invocation containing bang macro invocation #62325
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Comments
This is #43081, ultimately. The spans are dummy, as you can see, this means During pretty-printing we print Now thinking about this again, I'm not sure why we cannot print it as |
I recall it now. Hmm, perhaps the conversion should be enabled only if the token printing routine is called from inside of AST printing, but not otherwise. |
(I'll try to fix this tomorrow, shouldn't be too hard.) |
Fixed in #62393 |
…ulacrum Fix pretty-printing of `$crate` (take 4) Pretty-print `$crate` as `crate` or `crate_name` in unstructured tokens like `a $crate c` in `foo!(a $crate c)`, but only if those tokens are printed as a part of AST pretty-printing, rather than as a standalone token stream. Fixes rust-lang#62325 Previous iterations - rust-lang#56647, rust-lang#57155, rust-lang#57915.
## Motivation Currently, the `tracing` macros require curly braces as delimiters when a `format_args` macro is used in addition to structured fields, like: ```rust info!({ field1 = value1, field2 = value2 }, "unstructured message"); ``` This is confusing, since the delimiters are not used in other cases; it makes the syntax more complex; and, most importantly, I think it looks kind of ugly. I've been planning to get rid of this when we transition to procedural macros, but the transition is currently blocked on a compiler bug, rust-lang/rust#62325. (see #133 (comment)) I've been getting tired of waiting for this. ## Solution: This branch updates the `tracing` crate's macros to support a format_args message after the structured key-value fields without curly braces. For example, ```rust let yay = "WITHOUT DELIMITERS!!!"; info!(field1 = value1, field2 = value2, "message: {}", yay); ``` I've updated the tests & examples in the `tracing` crate so that they show this usage rather than the old usage. The old form with curly braces is still supported, since removing it would be a breaking change, but we'll transition it out in examples & tutorials. (can you put a `deprecated` attribute on a specific macro arm???). Signed-off-by: Eliza Weisman <eliza@buoyant.io>
When an attribute macro input contains
$ident
, it is correctly substituted both inside and outside of a function-like macro invocation i.e. both of the $ident's in[u8; $ident + m!($ident)]
would be substituted as expected.But when an attribute macro input contains
$crate
, it is only substituted outside of a function-like macro. Inside, it incorrectly disintegrates intoPunct('$'), Ident(crate)
when the whole bang macro invocation is passed to an attribute macro (or derive macro). In the case of[u8; $crate::N + m!($crate::N)]
the first $crate would be handled correctly but the second one would be passed incorrectly as two tokens. See where I put// WRONG
in the output below.Cargo.toml
src/main.rs
src/lib.rs
Output of cargo check:
Mentioning @petrochenkov who fixed my previous three $crate woes (#57089, #56622, #38016).
The text was updated successfully, but these errors were encountered: