Skip to content

Properly handle feature-gated lints #72694

Closed
@LeSeulArtichaut

Description

@LeSeulArtichaut

At the moment, the unsafe_op_in_unsafe_fn lint is the only feature-gated lint. However, feature-gate checks are hard-coded for this lint. If more feature gated lints are be added in the future, having proper handling for feature-gated lint will be useful.

Here is a suggested implementation plan:

  • Add a feature_gate field of type Option<Symbol> for the rustc_session::lint::Lint struct, which has a Some value if the lint is feature-gated, None otherwise.
  • Tweak the rustc_session::declare_lint! macro to allow specifying the feature gate when applicable, akin to future_incompatible.
  • When registering lints on the command line or for attributes, check if they are feature gated, and report errors accordingly. Basically, re-writing check_gated_link should be enough.
  • As rustdoc allows all lints as if they were passed on the command line, prevent rustdoc from allowing feature gated lints.

This issue has been assigned to @OddCoincidence via this comment.

Metadata

Metadata

Assignees

Labels

A-lintsArea: Lints (warnings about flaws in source code) such as unused_mut.C-cleanupCategory: PRs that clean code up or issues documenting cleanup.E-easyCall for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.E-mentorCall for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions