Add macro lifetime specifier

[Diggsey]

Allows accepting a lifetime as a parameter to a macro.

Fixes #23956

[rust-highfive]

r? @huonw

(rust_highfive has picked a reviewer for you, use r? to override)

[alexcrichton]

One point of possible worry is that lifetime is perhaps slated to become a keyword one day in accordance with the associated types RFC, it just has yet to be implemented.

[Diggsey]

I renamed it to use "life" instead of "lifetime" to avoid the conflict.

[Stebalien]

Bump? @huonw

[huonw]

Hm, I think this needs a few more pairs of eyes.

[nikomatsakis]

Seems like an RFC would make sense to work out naming etc. But also, this should be feature-gated.

[nikomatsakis]

During lang subteam mtg, we decided this should have an RFC, since it is a language extension, albeit a minor one. Removing nomination since we've taken a look (no priority needed).

[bors]

☔️ The latest upstream changes (presumably #27849) made this pull request unmergeable. Please resolve the merge conflicts.

[steveklabnik]

@Diggsey any interest in pursuing an RFC for this, like @nikomatsakis suggested?

[durka]

I'd be interested in helping with an RFC for this.

[durka]

It occurs to me that adding a fragment specifier for lifetimes doesn't actually fix significant situations where you might want to parse a lifetime specifier, for example in a list of generic parameters. In such a situation you would have to differentiate a lifetime specifier from an identifier, and in general a macro can't alternate on one fragment specifier vs another, unless this is actually a bug (cf #27832).

A design which could allow such alternation is not a new fragment specifier, but a (hopefully minor) modification to the lexer to allow '$ to parse. Then you could have a macro like this, using the apostrophe to differentiate. On the other hand this might be a terrible idea. Thoughts?

[alexcrichton]

Closing due to inactivity (and sounds like an RFC is desired)