Let qpath contain NtTy: <$:ty as $:ty>::…

[dtolnay]

Example:

macro_rules! m {
    (<$type:ty as $trait:ty>::$name:ident) => {
        <$type as $trait>::$name
    };
}

fn main() {
    let _: m!(<str as ToOwned>::Owned);
}

Previous behavior:

error: expected identifier, found `ToOwned`
 --> src/main.rs:3:19
  |
3 |         <$type as $trait>::$name
  |                   ^^^^^^ expected identifier
...
8 |     let _: m!(<str as ToOwned>::Owned);
  |            ---------------------------
  |            |
  |            this macro call doesn't expand to a type
  |            in this macro invocation

The expected identifier, found `ToOwned` error is particularly silly. I think it should be fine to accept this code as long as $trait is of the form TyKind::Path(None, path); if it is any other kind of NtTy, we'll keep the same behavior as before.

[rust-highfive]

r? @wesleywiser

(rust-highfive has picked a reviewer for you, use r? to override)

[bors]

☔ The latest upstream changes (presumably #85346) made this pull request unmergeable. Please resolve the merge conflicts.

[dtolnay]

• Rebased to resolve conflict with Account for incorrect impl Foo<const N: ty> {} syntax #85346

[petrochenkov]

This is very similar to #91166 (comment) (see it for some more details).

There's a definitive method to determine whether something interpolated should parse or not - checking how it would work in token-based expansion model (aka "how it would work in proc macro output"), as opposed to AST-based model that is currently used for implementing $interpolated fragments internally.

<$type as $trait>::$name in the example above will expand to <( str ) as ( ToOwned )>::Owned.
Should it parse? No, parentheses are not allowed inside a path.
So this change cannot go alone without some accompanying changes to $ty wrapping or path parsing.

Also see #67062 for the current issues with parsing Delimiter::Nones.

[dtolnay]

@petrochenkov:

<$type as $trait>::$name in the example above will expand to <( str ) as ( ToOwned )>::Owned.
Should it parse? No, parentheses are not allowed inside a path.

The following (where the rhs of as is $:path rather than $:ty) has worked all the way since Rust 1.0.0:

macro_rules! m {
    (<$t:ty as $p:path>::$name:ident) => {
        type $name = <$t as $p>::$name;
    };
}

m!(<str as ToOwned>::Owned);

so the path parsing already supports the "parentheses" in that position.

It's also supported in proc macro output already, for as long as Delimiter::None has existed (since Rust 1.29.0):

use proc_macro::{Delimiter, Group, Ident, Punct, Spacing, Span, TokenStream, TokenTree};

#[proc_macro]
pub fn repro(_input: TokenStream) -> TokenStream {
    // type T = <str as ⟪ToOwned⟫>::Owned;
    TokenStream::from_iter([
        TokenTree::Ident(Ident::new("type", Span::call_site())),
        TokenTree::Ident(Ident::new("T", Span::call_site())),
        TokenTree::Punct(Punct::new('=', Spacing::Alone)),
        TokenTree::Punct(Punct::new('<', Spacing::Alone)),
        TokenTree::Ident(Ident::new("str", Span::call_site())),
        TokenTree::Ident(Ident::new("as", Span::call_site())),
        TokenTree::Group(Group::new(Delimiter::None, TokenStream::from_iter([
            TokenTree::Ident(Ident::new("ToOwned", Span::call_site()))
        ]))),
        TokenTree::Punct(Punct::new('>', Spacing::Alone)),
        TokenTree::Punct(Punct::new(':', Spacing::Joint)),
        TokenTree::Punct(Punct::new(':', Spacing::Alone)),
        TokenTree::Ident(Ident::new("Owned", Span::call_site())),
        TokenTree::Punct(Punct::new(';', Spacing::Alone)),
    ])
}

So this change cannot go alone without some accompanying changes to $ty wrapping or path parsing.

Given the above, I can't tell what other change you have in mind by this.

[petrochenkov]

Ah, ok, if $path is already supported then no additional changes are required.

It's also supported in proc macro output already, for as long as Delimiter::None has existed

The current parser currently eliminates all Delimiter::Nones before parsing (and it's a source of bugs, #67062), so it doesn't mean much.

[wesleywiser]

r? rust-lang/compiler-team

[wesleywiser]

r? compiler-team

[Mark-Simulacrum]

r? compiler-team

(trying to trigger some logs for this case)

[davidtwco]

Apologies for the time this has taken to be reviewed.

@bors r+

[bors]

📌 Commit 87a7def has been approved by davidtwco