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

[dtolnay]

Example:

macro_rules! m {(<$type:ty as $trait:ty>::$name:ident) => {
<$type as $trait>::$name
};}fnmain(){let _:m!(<strasToOwned>::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!(<strasToOwned>::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]pubfnrepro(_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