Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

<$t:ty> falls victim to C++ >> ambiguity #37175

Closed
durka opened this issue Oct 14, 2016 · 2 comments
Closed

<$t:ty> falls victim to C++ >> ambiguity #37175

durka opened this issue Oct 14, 2016 · 2 comments

Comments

@durka
Copy link
Contributor

durka commented Oct 14, 2016

Consider this macro:

macro_rules! m { (<$t:ty>) => { stringify!($t) } }

Unfortunately it can't deal with a type that ends in >:

m!(<Vec<i32>>)
error: no rules expected the token `>>`
 --> .cargo/.cargo/script-cache/expr-edcce559d98013ba/expr.rs:5:64
  |
5 | {macro_rules! m { (<$t:ty>) => { stringify!($t) } } m!(<Vec<i32>>)}
  |                                                                ^^

error: Could not compile `expr`.

Is it possible to fix this? It seems to me the macro parser should know it's parsing $t:ty and therefore >> can't be valid, so it should be split into two tokens.

cc @jseyfried

@jseyfried
Copy link
Contributor

jseyfried commented Oct 14, 2016

@durka yeah, this is definitely possible to fix.

The parser already splits the >> into two tokens and parses the type correctly -- the problem appears to be that we drop that parser once we finish parsing the type and just keep the underlying Reader (stream of tokens), which doesn't know that the >> has been partially consumed (c.f. the call to parse_nt in syntax/ext/tt/macro_parser.rs).

To fix this, we could to have the parser mutate the >> into a > in the Reader (currently, we can only consume tokens from a Reader). Or, we could also check if there is a partially consumed token before dropping the parser and keep track of it locally in macro_parser::parse.

@jseyfried
Copy link
Contributor

Fixed in #37208.

eddyb added a commit to eddyb/rust that referenced this issue Oct 19, 2016
…kens_in_macros, r=nrc

macros: fix partially consumed tokens in macro matchers

Fixes rust-lang#37175.

This PR also avoids re-transcribing the tokens consumed by a matcher (and cloning the `TtReader` once per matcher), which improves expansion performance of the test case from rust-lang#34630 by ~8%.

r? @nrc
eddyb added a commit to eddyb/rust that referenced this issue Oct 19, 2016
…kens_in_macros, r=nrc

macros: fix partially consumed tokens in macro matchers

Fixes rust-lang#37175.

This PR also avoids re-transcribing the tokens consumed by a matcher (and cloning the `TtReader` once per matcher), which improves expansion performance of the test case from rust-lang#34630 by ~8%.

r? @nrc
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants