Skip to content

refactor lint mechanism to support "error in new edition, lint in older editions" pattern #84625

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
nikomatsakis opened this issue Apr 27, 2021 · 4 comments
Closed

refactor lint mechanism to support "error in new edition, lint in older editions" pattern #84625

nikomatsakis opened this issue Apr 27, 2021 · 4 comments
Labels
C-cleanup Category: PRs that clean code up or issues documenting cleanup. E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@nikomatsakis
Copy link
Contributor

nikomatsakis commented Apr 27, 2021 •
edited
Loading

We've been adding lints that, in newer editions, become hard errors. Right now we do this by manually creating either an error or a lint. (see e.g. #83213). We should introduce an API where we write one specification and the compiler decides, based on the edition of a particular span, whether to introduce a hard error or not.
@nikomatsakis nikomatsakis added E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. C-cleanup Category: PRs that clean code up or issues documenting cleanup. labels Apr 27, 2021
@nikomatsakis
Copy link
Contributor Author

I've marked this as E-mentor. I'm game to help someone with it!

Some mentoring notes:

@nikomatsakis nikomatsakis mentioned this issue Apr 27, 2021
Merged
@petrochenkov
Copy link
Contributor

BARE_TRAIT_OBJECT is not a good case for using such mechanism - #83213 (comment).

@nikomatsakis
Copy link
Contributor Author

OK; the mechanism may not be used enough to warrant existing =)

@nikomatsakis
Copy link
Contributor Author

After some discussion, decided this is premature.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
C-cleanup Category: PRs that clean code up or issues documenting cleanup. E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@nikomatsakis @petrochenkov