Tracking issue for the quote! macro in proc_macro

View all comments

I'm splitting this off #38356 to track the quote! macro specifically contained in proc_macro. This macro has different syntax than the quote crate on crates.io but I believe similar functionality. At this time it's not clear (to me at least) what the status of this macro is in terms of how much we actually want to stabilize it or what would block its stabilization. Others are welcome to fill this in though!

Steps / History

RFC: https://rust-lang.github.io/rfcs/1566-proc-macros.html
Implementation: proc_macro: implement TokenTree, TokenKind, hygienic quote!, and other API #40939
Stabilization:

Unresolved questions

proc_macro::quote does not work with interpolated constant inside repetition #146603
Should this use $ to match other macros or # to drop in with quote::quote? Tracking issue for the quote! macro in proc_macro #54722 (comment)
Which spans should be used? Tracking issue for the quote! macro in proc_macro #54722 (comment)

From #54722 (comment):

Do we want our own version of quote::ToTokens rather than relying on From? Changed in Tracking Issue for proc_macro::ToTokens #130977
Should we add repetition before stabilization?

Ah, and this is also tracking the proc_macro_quote feature.

@petrochenkov

We need to avoid .clone()-ing the variables interpolated by quote!, we should have &T -> TokenStream (or, better, an append taking &T, &mut TokenStream, like the quote crate).

EDIT: thinking more about it, I think we should support TokenStream, all the proc_macro types that convert to TokenStream, including references of all of those, and, on top of that, anything that .extend(...) on a TokenStream would take (I haven't checked, do we implement Extend for it?).

I don't like $$ used for escaping $, I'd prefer if \$ was used (we could make $$ an error for now).

We should make sure we error on $(...) even if we don't start supporting repetition syntax right away, to reserve the right to do so in the future.

And maybe we should consider ${...} for nesting expressions, but, again, as long as any unsupported syntax that starts with $ errors, we can extend it later.

There's also the question of what to do about spans. The quote crate has a version of the macro that also takes Span, but I'd prefer pointing to the proc macro source where quote! was used.

For this, we can use an unstable Span constructor that takes a SourceFile reference and a byte range into that, and an unstable constructor for SourceFile that provides all the per-file SourceMap information (file path, expected content hash, line map, etc.) the compiler needs.
Making def-site hygiene also work would be trickier, but not impossible AFAIK.

cc @petrochenkov

I don't like $$ used for escaping $, I'd prefer if \$ was used (we could make $$ an error for now).

Yes please.

I'm wondering what the reasoning is behind the preference for \$ over $$.
Is it purely a syntactic style preference? Or is there more to it?

I ask because as I see it (but without announcing a preference either way), $$ has the advantage of being easier to type for pretty much everyone, while it has the disadvantage of being less easy to read for e.g. people with dyslexia.

@jjpe

@jjpe As I see, there are two main reasons: 1) easier to read (can be picked out at a glance with less difficulty), 2) agrees with long-established convention of backslash escapes (beginning with C I think, but existing in most current languages for strings, including Rust).

Furthermore, it will probably be more common to escape $ than it will be to escape \ in macros.

@alexreg

@alexreg, main advantage of $$ is that it does not need another special character. In this case there is only one, so adding another doubles the complexity. If there were more special characters, a common escape would make sense, but in this case there is only one and most of the languages that have only one special character escape it by doubling it.

@jan-hudec

@jan-hudec That's not a real advantage to me. There's no additional complexity, when you already have all of those chars in the syntax. And I think the two reasons I gave above are more pertinent.

I’d argue that # is better, since it lets you generate declmacros without escaping. I’m not sure what are the advantages of $ here.

Apropos of proposed RFC 3607, we're considering an .#tag syntax for accessing the discriminant of an enum. See here.

More generally, we find ourselves wanting to use the # syntax space (e.g.), and so an interpolation syntax that doesn't conflict with that has some appeal.

So concretely, the hardest blockers seem to be:

Stabilize Span::def_site() OR make quote! use Span::{call,mixed}_site() OR otherwise address the span issue so that we don't compromise diagnostics
(ahem) hash out any details about the unquoting syntax
bjorn3's remark about hygiene which might be 1 again (I haven't expanded the tokens fully yet)

At least personally, I consider "feature-parity with the crate" to be a huge "nice-to-have" and something that's easy to use as a block to ever shipping this. We should focus mainly on those that we expect to be essentially impossible to simply tack on later, which will probably include...

deciding on including repetition or not

Rollup merge of rust-lang#134693 - SpriteOvO:proc-macro-use-to-tokens…

Unrolled build for rust-lang#134693

Rollup merge of rust-lang#134693 - SpriteOvO:proc-macro-use-to-tokens…

What's the behavior with strings? For example would

quote! {
    println!("$ident")
}

be interpreted as templating the $ident into the string or would the string be literally "$ident"? If it is in the case of the former would raw strings have an exception?

@ora-0

@ora-0 It would be the literal string "$ident". If you wanted it to be a string with the contents of $ident, you'd need to use

let ident = ident.to_string();
quote! {
    println!($ident)
}

@dtolnay

@dtolnay said

One other difference besides repetitions and $ vs # is that the external quote is unit testable -- the proc_macro quote produces a proc_macro::TokenStream which can only exist within the context of a procedural macro, so any functions or helper libraries that you write using proc_macro quote will panic when called from a unit test.

See:

Tracking issue for proc_macro in non-proc-macro crates #130856

I'm not sure if this should block stabilization or not: while it's not needed to make this work, it does seem like a serious deterrent to testing by actual users, what with the, um, testing difficulties...

Navigation Menu

Repository navigation

Tracking issue for the `quote!` macro in `proc_macro` #54722

Steps / History

Unresolved questions

37 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Tracking issue for the quote! macro in proc_macro #54722

Description

Steps / History

Unresolved questions

Activity

alexcrichton commented on Oct 1, 2018

eddyb commented on Nov 3, 2018

alercah commented on Jan 9, 2019

alercah commented on Jan 9, 2019

alexreg commented on Jan 9, 2019

jjpe commented on Jan 9, 2019

alexreg commented on Jan 9, 2019

jan-hudec commented on Jan 9, 2019

alexreg commented on Jan 10, 2019

37 remaining items

GoldsteinE commented on Aug 21, 2024

traviscross commented on Aug 21, 2024

workingjubilee commented on Aug 30, 2024

ora-0 commented on May 26, 2025

jhpratt commented on May 26, 2025

SamB commented on Apr 27, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Tracking issue for the `quote!` macro in `proc_macro` #54722