Write lint for usage of edition-gated keywords

[Manishearth]

After #49611 lands, attempting to use async as an identifier will work if on the 2015 edition, but not on the 2018 edition.

So that editions can be rustfixed, we need the ability to lint this and suggest fixes.

[Manishearth]

This is trickier than usual. We want to run this lint for code actually specified in this crate -- ideally in the place where we lex the tokens. So code from a macro from a different crate should not trigger the lint, but code within a macro def/invocation from this crate should.

However, the lint levels aren't available to the lexer. We can persist this info till parsing and lint there, but the lint levels aren't available there either.

The node IDs used during parsing are dummy ids, so we cannot stash the lint info there and emit it lated.

The way I see it, we have the following options:

• Emit lints during lexing, somehow figure out lint levels (afaict this may be fundamentally impossible)
• Emit lints during parsing, somehow figure out lint levels (doable, but we're kinda reinventing the lint framework)
• Emit lints as an extra-early lint pass running before macro expansion: By now the spans of the tokens within macro defs and invocations are missing, so this is hard to do well. We can still do it but the suggestions for macros won't work.
• Emit lints as a regular early or late pass: Macro invocations are now missing completely.

thoughts? @nikomatsakis @oli-obk @eddyb

[oli-obk]

We could stash the lints with their span instead of an ID. This is doable in the lexer. Then, later, we can run a normal early lint pass which only does lint level checking and runs through the list of stashed lints and checks whether their span is a subset of any span it encounters.

Not sure whether those spans would still match after expansion, so maybe we need that pre expansion lint pass

[rcoh]

Hey, I'd like to take a stab at this, if someone wouldn't mind pointing me in the right direction.

• By "lint level" do you just mean what the current lint configuration is?

@oli-obk just so I understand what you're suggesting: We add the ability to persist partial-lint information in the tokens emitted by the lexer, then later pull the lint information back out again once we have actual ids for things?

[Manishearth]

By "lint level" do you just mean what the current lint configuration is?

The lint level is whether or not a particular lint is allow/warn/deny. We'd be doing this for a single lint. We could keep track of info for all lints but that's not necessary.

Note that #49611 hasn't landed yet and @petrochenkov is redoing the approach, so there's a chance the approach for this issue won't work anymore. But I don't think that's going to be the case, so you can go ahead with writing the framework code without writing the lint itself.

[pnkfelix]

visiting for triage

assigning to @oli-obk to make sure that this gets mentoring instructions (or outright implemented), hopefully before Preview 2.

[alexcrichton]

A PR for this is now at #52375