Make ast::Lifetime contain ast::Name instead of ast::ident

[lilac]

Fixes#7743. To make the compiler happy, I rewrite a use case of the "quote_item" macro. After we get a compiler snapshot that includes this change, the manual ast construction can be reverted back to using "quote_item".

[huonw]

Wow, nice work! Could you put a note here, e.g.

// NOTE: Cannot use quote_item due to stage0 and #7743, revert after a snapshot

[lilac]

Great, I just want to add something like FIXME, but don't know how to express that uniformly.

[lilac]

How about this:
// FIXME: Cannot use lifetimes in quote_item due to stage0 and #7743, revert after a snapshot

[huonw]

That's fine, but it has to be a NOTE, or you have to file an issue, and write FIXME #nnnn ... (which is fine too). make tidy doesn't allow FIXME without an issue number.

[lilac]

OK, get it.

[emberian]

@lilac in the future, when you update a PR, do r? @whoeverreviewedit to make sure it doesn't languish in the queue.

[lilac]

@cmr OK, thanks!

[huonw]

@lilac it looks like this failed with the same error as #8103 (i.e. make: *** [i686-pc-mingw32/stage1/bin/rustc/i686-pc-mingw32/bin/std.dll] Error 255), so if/when that gets fixed, this can probably go through too.

[jbclements]

I'm interested, because afaict there's not actually any shared code between this and #8103 . FWIW, @graydon tells me that he reduced the failure to this code:

macro_rules! ok (($T:ident) => ($T))
macro_rules! bad (($T:ty) => ($T))
//ok!(int); // compiles
bad!(int); // crashes
fn main() { }

Unfortunately, I don't have a Windows machine to reproduce this failure. If you ( @lilac ) do, perhaps you can see whether this code triggers the failure on your PR, too?

Best,

John

[lilac]

@jbclements Sorry, I don't have a Windows machine neither. And I am quite surprised that two unrelated pieces of code result in the same error.

Maybe because the macro usage and my manual AST tree building both call some underlying AST related codes?

[lilac]

r? @huonw

[huonw]

Hm, @lilac, this doesn't merge cleanly, could you rebase on top of master?

[lilac]

@huonw Rebase done. Do I need to close this PR and create a new PR after rebase?

[huonw]

Nope, no need for a new PR, just force pushing the updated commits to this PR is fine.

[lilac]

r? @huonw

[lilac]

@bors: retry

[huonw]

(You need to be a reviewer to @bors: retry. :) )

We've accumulated a long chain of commits, could you squash them into the first one since it's all a single feature?

[lilac]

@huonw I still haven't known the reason for

it looks like this failed with the same error as #8103 (i.e. make: *** [i686-pc-mingw32/stage1/bin/rustc/i686-pc-mingw32/bin/std.dll] Error 255), so if/when that gets fixed, this can probably go through too.

Not sure if it worths a retry.

[catamorphism]

@lilac Needs a rebase.

[catamorphism]

Closing due to lack of activity. Please reopen if you have time to rebase it!

[jbclements]

my patch went through, so this one might as well. I'll re-open it when I have time to do some baby-sitting.