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

[nikomatsakis]

cc https://github.com/rust-lang/rfcs/pull/1590 @sgrif

[sgrif]

I'll open a new PR soon, I want to do one more thing on top of https://github.com/rust-lang/rust/pull/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 https://github.com/rust-lang/rust/pull/41012/commits/e0cd76674d3f5cf68d83789bad27dec9dcf53501, and https://github.com/rust-lang/rust/pull/41012/commits/1d468050574cc28a06ef684727e1106fa660a20c, and https://github.com/rust-lang/rust/pull/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:

• [x] @aturon
• [x] @cramertj
• [x] @eddyb
• [x] @nikomatsakis
• [x] @nrc
• [x] @pnkfelix
• [ ] @withoutboats

Concerns:

• underscore-lifetime resolved by https://github.com/rust-lang/rust/issues/34303#issuecomment-374656102

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 [e-mail]
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
https://github.com/rust-lang/rust/issues/34303#issuecomment-373439566,
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]

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

[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. :cry: I filed https://github.com/rust-lang/rust/issues/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.