-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Macro system apparently has trouble with nested token trees #3201
Labels
A-syntaxext
Area: Syntax extensions
Milestone
Comments
A minimal test case would be helpful. |
paulstansifer
added a commit
to paulstansifer/rust
that referenced
this issue
Nov 27, 2012
paulstansifer
added a commit
to paulstansifer/rust
that referenced
this issue
Nov 27, 2012
The syntax in the bug report is out-of-date. Here's a lambda calculus interpreter in Rust's macro system (working as of 028eeb1, according to my super superficial testing).
|
RalfJung
pushed a commit
to RalfJung/rust
that referenced
this issue
Dec 3, 2023
celinval
pushed a commit
to celinval/rust-dev
that referenced
this issue
Jun 4, 2024
Dependency upgrade resulting from `cargo update`. Co-authored-by: tautschnig <1144736+tautschnig@users.noreply.github.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The title is my best hypothesis for what's happening. It is probably wrong.
I have a set of macros that should implement a lambda calculus interpreter:
I can use this to interpret a lambda calculus term:
This evaluates as follows, which is clearly wrong:
However, if I copy the last line in the macro trace and try to run that, I get a little further:
If I repeat the process, I get:
And again...
And again...
The last line,
(closure y.[#y]:)
, is what I would expect the original expression to evaluate to. The fact that repeated invocation causes us to make a little more progress each time makes me think there's a bug in how macro parsing works.The text was updated successfully, but these errors were encountered: