Allow `for` to follow path fragment in macro_rules

language design
1

Without this, implementations cannot be parsed:

my_macro! {
  impl std::ops::Add for X {}
}

Is there some policy for which parts of the standard Rust syntax macro_rules should and should not be able to parse?

macro_rules my_macro! {
  (impl p:path for t:ty) => {}
}
// `$r#p:path` is followed by `for`, which is not allowed for `path` fragments
1 Like
2

I don’t think that for can reasonably terminate a path, given that this compiles today:

macro_rules! my_macro {
  (impl $p:path {}) => {};
  (impl $p:path, for $t:ty {}) => {};
}

my_macro! {
  impl Fn() -> impl for <A>::Blah {}
}

my_macro! {
  impl Fn() -> impl, for <A>::Blah {}
}

(playground)

I’m not sure if this really implies that there is no way to add a way to for-terminate a path for macros (in a backwards-compatible way), but at least it’s not as straightforward as one might initially assume.

5 Likes
3

It is documented in the reference:

https://doc.rust-lang.org/nightly/reference/macros-by-example.html#follow-set-ambiguity-restrictions

https://doc.rust-lang.org/nightly/reference/macro-ambiguity.html

2 Likes
4

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.