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

[alexcrichton]

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

• 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?

[alexcrichton]

Ah, and this is also tracking the proc_macro_quote feature.

[eddyb]

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

[alercah]

I just tried this out and $a quoting doesn't seem to work at all. It doesn't even error on $# like I'd expect from the source.

[alercah]

Oh nevermind, I was using it wrong.

[alexreg]

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

Yes please.

[jjpe]

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.

[alexreg]

@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.