Tracking issue for adding a `lifetime` specifier to `macro_rules!`

[nikomatsakis]

cc rust-lang/rfcs#1590 @sgrif

[sgrif]

I'll open a new PR soon, I want to do one more thing on top of #33135

[Phlosioneer]

Godspeed, @sgrif! This being in nightly would make my week.

[comex]

@sgrif Any update?

[brson]

This doesn't seem particularly hard. Help wanted.

[durka]

I wish we knew what the "one more thing" was besides just reopening the closed PR.

[mikeyhew]

I'd like to help implement this. Where do I start?

[petrochenkov]

@mikeyhew
This is a good issue to start working on the compiler frontend.
You may want to start with taking @sgrif's patch and rebasing it on the current master, and then making sure the tests pass.
Then you'll have to add a feature gate for lifetime matcher and some docs (unstable book section) (see e0cd766, and 1d46805, and #41012 as a whole for examples of the same things being done with vis matcher.)

@durka

I wish we knew what the "one more thing" was besides just reopening the closed PR.

This should be something truly marvelous, that this GitHub comment was too narrow to contain.

[sgrif]

This issue should remain open until the feature is stable, right?

[cramertj]

@rfcbot fcp merge

AFAIK this feature has gone relatively without-incident since its implementation, and it adds key functionality to macros. Tests can be found here, here, here, and here.

[petrochenkov]

Some alternatives are discussed in https://internals.rust-lang.org/t/pre-rfc-splitting-lifetime-into-two-tokens/6716 - either splitting lifetimes into two tokens, then they can be matched with ' $i: ident or just making them identifiers so the can be matched with $i: ident / $'i: ident.

I don't think it prevents stabilization of the lifetime matcher, if those changes are implemented it will still continue to work and we'll be able to deprecate it if necessary.

[cramertj]

@rfcbot fcp merge

trying again

[nikomatsakis]

@rfcbot fcp merge

See @cramertj's brief summary here.

[rfcbot]

Team member @nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged teams:

• @aturon
• @cramertj
• @eddyb
• @nikomatsakis
• @nrc
• @pnkfelix
• @withoutboats

Concerns:

• underscore-lifetime resolved by #34303 (comment)

Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[nikomatsakis]

@rfcbot fcp concern

@petrochenkov recently brought it to my attention that '_ matches the lifetime fragment (whereas _ -- rightly, to my mind -- does not match ident). I believe this is incorrect, or at least worth debating. =) '_ is not a lifetime name, it is rather a token used to control elision rules.

On the other hand, I can see an argument that not supporting '_ means we can't "forward" lifetimes in some cases where we would like to. (I suppose a similar argument would apply to _ and ident.)

[nikomatsakis]

@rfcbot concern underscore-lifetime

[nikomatsakis]

(Bother, I can never remember the dang syntax.)

[durka]

If I understand correctly, '_ is going to become very common very soon because elision on structs will be partially removed, meaning `struct Foo<'a>(&'a str); fn bar(&str) -> Foo {...}` turns into `fn bar(&str) -> Foo<'_>`. (Biting my tongue about my thoughts on that change because it's irrelevant to this issue.) In that case I think users will be very confused if `m!(Foo<'a>)` works but `m!(Foo<'_>)` doesn't. We are adding this feature to make macros more flexible. You could still match '_ and 'a using two rules (one with literal '_ and one with $lt:lifetime) but why throw up that arbitrary barrier? _ as ident is a separate thing but at least it does match as a pat.

…

On Thu, Mar 15, 2018 at 12:32 PM, Niko Matsakis ***@***.***> wrote: (Bother, I can never remember the dang syntax.) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#34303 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAC3n2QjhQ2VQW3En09_RyWhNU_DluNzks5tepexgaJpZM4I3Wep> .

[nikomatsakis]

@durka right, that's precisely what I was thinking when I wrote the "on the other hand" part. I think I'm going to resolve my concern -- otherwise I guess we need a bunch more matchers.

@rfcbot resolve underscore-lifetime

[durka]

@nikomatsakis please say "resolved" for the bot

[nikomatsakis]

@rfcbot resolved underscore-lifetime

Sigh.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[rfcbot]

The final comment period is now complete.

[durka]

🚀 🚀 🚀 🚀 🚀

[dtolnay]

We don't have tests for a macro_rules falling through to the next rule after a $:lifetime matcher.

And it doesn't work. 😢 I filed #51477 to follow up.

[Centril]

I think we can close this as it was stabilized; bugs and other things can be tracked as we usually do.