Repository navigation
Write lint for usage of edition-gated keywords #49716
Description
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.
Metadata
Metadata
Assignees
Labels
Area: The 2018 editionArea: Lints (warnings about flaws in source code) such as unused_mut.Category: An issue proposing an enhancement or a PR with one.Call for participation: Medium difficulty. Experience needed to fix: Intermediate.High priorityRelevant to the compiler team, which will review and decide on the PR/issue.Working group: Epoch (2018) management
Activity
Manishearth commentedon Apr 5, 2018
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:
thoughts? @nikomatsakis @oli-obk @eddyb
oli-obk commentedon Apr 6, 2018
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 commentedon Apr 17, 2018
Hey, I'd like to take a stab at this, if someone wouldn't mind pointing me in the right direction.
@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 commentedon Apr 17, 2018
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 commentedon Jul 12, 2018
visiting for triage
assigning to @oli-obk to make sure that this gets mentoring instructions (or outright implemented), hopefully before Preview 2.
alexcrichton commentedon Jul 17, 2018
A PR for this is now at #52375
Auto merge of #52375 - oli-obk:the_early_lint_pass_gets_the_worm, r=M…