Invisible delimiters quoted for `Group`

[ascjones]

When using a a proc macro from within a declarative macro, a ty is expanded to a Group.

With the latest nightly 1.63.0-nightly (42e1761c7 2022-05-15) the invisible delimiters now appear in the quoted tokens e.g.

• before bool,
• after /*«*/ bool /*»*/

Two-crate test case

Crate derive, Cargo.toml

[package]
name = "derive"
version = "0.0.0"
edition = "2018"

[lib]
proc-macro = true

[dependencies]
quote = "1"
proc-macro2 = "1.0"
syn = "1.0"

Crate derive, src/lib.rs

extern crate proc_macro;
use proc_macro::TokenStream;

use syn::{parse_macro_input, DeriveInput};
use quote::quote;

#[proc_macro_derive(MyDerive)]
pub fn my_derive(input: TokenStream) -> TokenStream {
    println!("{}: {:?}", input, input);
    let input: DeriveInput = syn::parse(input).unwrap();

    if let syn::Data::Struct(s) = input.data {
        for f in s.fields {
            let ty = f.ty;
            match &ty {
                syn::Type::Group(group) => {
                    let ty = &group.elem;
                    println!("Type::Group {:?}", quote!(#ty));
                },
                _ => println!("Type::Other"),
            }
            // prints '/*«*/ bool /*»*/` with nightly rustc 1.63.0-nightly (42e1761c7 2022-05-15)
            // prints 'bool' with current stable rustc 1.60.0 (7737e0b5c 2022-04-04)
            println!("{}", quote!(#ty))
        }
    }

    quote!{ }.into()
}

Crate impl, Cargo.toml

[package]
name = "impl"
version = "0.1.0"
edition = "2021"

[dependencies]
derive = { path = "../derive", versiom = "0.0.0" }

Crate impl, src/lib.rs

macro_rules! gen_struct_with_type {
    ( $ty:ty ) => {
        #[derive(derive::MyDerive)]
        struct S($ty); // This type is parsed as a `Group` so the delimeters get added to the quoted tokens
    };
}

#[derive(derive::MyDerive)]
struct T(bool);

gen_struct_with_type!(bool);

Looking at recent commits, this looks suspicious: #95159. Related #96305 (comment).

[petrochenkov]

Invisible delimiters are pretty-printed starting from #96682, this was an intentional change.
Do they cause any issues?
cc @nnethercote

[ascjones]

Do they cause any issues?

It does, but if it was intentional then I can account for it.