ctxts on macro invocations won't work in some places

[jbclements]

The current scheme of attaching contexts to macro invocations won't work correctly when that macro invocation is inside of another macro definition, because that definition will be represented only as token trees, and the macro invocation won't accumulate context correctly.

There are a couple of possible fixes for this. One would be to back out the existing scheme and just use the context associated with the macro invocation identifier--that is, the 'foo' in an invocation foo!(3,4,5). A better way of doing it--if it's not too expensive--would be to add a context to every tt_delim, and then transfer it correctly to a tt_delim that parses into a macro invocation.

[thestinger]

triage bump

[jbclements]

I still think both of these solutions would work fine. Is this coming up in practice?

[huonw]

(triage)

I don't exactly understand the problem here (i.e. will it cause a failure of hygiene?); @jbclements, do you happen to have a code example demonstrating it?

[uorbe001]

I seem to have stumbled upon this same issue, this gist shows it. I get an "unresolved name a" on the linked line, which doesn't happen if I change it to something like if !(1i == a) {} instead of assert!.

[pnkfelix]

cc me

[jbclements]

@uorbe001 no... that doesn't sound like this issue. I'm working on reproducing your issue....

[uorbe001]

@jbclements any way I can help? I can try to make a simplified code sample if that helps

[jbclements]

@uorbe001 wurf... I can't reproduce your issue without all of your code. Looks like there's a dependency on 'rustspec'. Apologies if I'm missing something obvious.

[uorbe001]

@jbclements I'll try to reproduce it without it in a few days, I'm a bit busy atm ;)

[uorbe001]

@jbclements I managed to reproduce it without my library, the code is kind of messy, but it fails. I've been trying to remove stuff that might not be important for this code, but I'm kind of stuck, if you can see something that is superfluous and can make it easier to read by removing it, let me know and I'll update the gist: https://gist.github.com/uorbe001/1118f22c378d2e382d29

I think the problem might be related to the fact that I'm calling to_tokens on a block and creating a new parser with that, and the hygiene check might be going nuts, but my understanding of how the compiler (or anything in rust for that matter) is pretty limited.

Does this sound like part of this issue, or should I add the gist on a different one?

[jbclements]

Ah! You’re cheating :). Put differently: this isn’t a simple pattern macro, you’re messing around with tokens directly.

Can you help me out a bit more and tell me what this macro (mymacro!) is supposed to do? I can partially see it, but maybe you can spell it out explicitly for me?

[uorbe001]

The macro is supposed to allow me to define contexts for different test cases to reuse setup/dropdown methods and provide more context for each test case. It's essentially a port of rspec and similar frameworks from other languages, you can see how I intend to use it here: https://github.com/uorbe001/rustspec/blob/master/tests/test.rs#L20

[jbclements]

Okay, that makes sense.

First thing: this is almost certainly not related to this issue.

Second thing: something like this should work, yes; hygiene should be working with you, here, not against you. It should be possible to rearrange the pieces at will, and "just work". So I do think that there's a hygiene issue here, probably related (as you point out) to the re-parsing of the trees. Can you open a separate issue for this?

[uorbe001]

@jbclements done ;-)

[steveklabnik]

This bug has long been open, and there hasn't been a lot of recent discussion. Macros aren't @jbclements , a reproduction would be nice if you still think this is a relevant issue. Thanks!

[jbclements]

@steveklabnik , is there a macros czar? What's the state of macros in Rust these days?

[steveklabnik]

Whoah, first of all, sorry for the half-sentence in the previous mention. What I was going to say is relevant to your question:

What's the state of macros in Rust these days?

Basically, we reserved a macro keyword for 'macros 2.0'. We know that the current macro design has flaws, and because of backwards compatibility, we won't be removing macro_rules. But because a 2.0 will someday come, nobody is really the czar at the moment.

rust-lang/rfcs#440 is the tracking issue for macros++.

That said, if people are interested in fixing macro issues, we're accepting improvements. I'm fine with re-opening this issue, it was just a year since the last bit of discussion and no direct reproduction, so I figured it was closeable.

[jbclements]

On Sep 3, 2015, at 10:57 AM, Steve Klabnik notifications@github.com wrote:

Whoah, first of all, sorry for the half-sentence in the previous mention. What I was going to say is relevant to your question:

What's the state of macros in Rust these days?

Basically, we reserved a macro keyword for 'macros 2.0'. We know that the current macro design has flaws, and because of backwards compatibility, we won't be removing macro_rules. But because a 2.0 will someday come, nobody is really the czar at the moment.

rust-lang/rfcs#440 is the tracking issue for macros++.

That said, if people are interested in fixing macro issues, we're accepting improvements. I'm fine with re-opening this issue, it was just a year since the last bit of discussion and no direct reproduction, so I figured it was closeable.

Okay, sounds good. Thanks!

John