Implement edition-gated keywords

[Manishearth]

We want to reserve a bunch of keywords in the 2018 edition. There's a full list of potential keywords, but for now I'll probably just reserve async, await, and catch.

EDIT: Here's my preliminary review of potential keywords and stuff: https://hackmd.io/lu7wxNbRTuO3C0NITUum6Q?both# // @Centril

For edition hygiene reasons this will be done entirely at the lexer level. Keywords in Rust are all lexed as identifiers, however you can have "raw identifiers" which let you create idents treated explicitly as idents. We overload this, so that if the lexer comes across the identifier "async" on Rust 2015, it lexes it as if it were r#async. We may want to fix it up in the pretty printer as well.

[Manishearth]

An alternate fix is to have a second flag on Ident, which marks whether or not it's allowed to form a keyword. This has the additional benefit of being easier to work with for promoting contextual keywords to full keywords.

[Manishearth]

Actually, not doing catch yet, it's contextual.

[Manishearth]

Ah, catch is currently implemented in an unstable form as do catch. We can change this whenever we like so that it doesn't work for the 2015 epoch and in 2018 uses a non-contextual catch keyword.

[Manishearth]

#49611

[cramertj]

Why do async and await need to be non-contexutal keywords? AFAIK at least async could be added backwards-compatibly as a contextual keyword.

[Manishearth]

Because I picked the two keywords I knew we definitely wanted 😄 (most of the others are under discussion or otherwise iffy).

I wasn't aware we were fine with them as contextual keywords -- I thought we wanted to epochify anything that we may need as a keyword in the next epoch.

Personally I'd rather add things as full keywords. But thinking about it I guess it would be nice if Rust 2015 got async/await as well.

However, AFAICT await will have to be a real keyword? Or it will be prone to the same issue we have with catch (which causes do catch)? And if await is going to be a 2018-only keyword it seems like the entire feature should just be 2018-only, in which case, why not make async a full keyword.

idk 😄

[cramertj]

why not make async a full keyword

Because I have preexisting modules named async 😛 lol

[Manishearth]

r#async all the way 😛

[Manishearth]

@nikomatsakis thoughts on what we should be doing here?

As mentioned in Gitter, we can do this for dyn as well -- no dyn at all in 2015, and dyn becomes a full keyword in 2018. I kinda prefer that.

cc @Centril