Skip to content

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

New issue

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

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

Already on GitHub? # to your account

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
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants