-
Notifications
You must be signed in to change notification settings - Fork 2k
Move our paths over to diagnostic items #5393
Copy link
Copy link
Closed
rust-lang/rust
#142787Labels
C-an-interesting-projectCategory: Interesting projects, that usually are more involved design/code wise.Category: Interesting projects, that usually are more involved design/code wise.C-tracking-issueCategory: Tracking IssueCategory: Tracking IssueE-mediumCall for participation: Medium difficulty level problem and requires some initial experience.Call for participation: Medium difficulty level problem and requires some initial experience.G-performance-projectGoal: For issues and PRs related to the Clippy Performance ProjectGoal: For issues and PRs related to the Clippy Performance Project
Description
Metadata
Metadata
Assignees
Labels
C-an-interesting-projectCategory: Interesting projects, that usually are more involved design/code wise.Category: Interesting projects, that usually are more involved design/code wise.C-tracking-issueCategory: Tracking IssueCategory: Tracking IssueE-mediumCall for participation: Medium difficulty level problem and requires some initial experience.Call for participation: Medium difficulty level problem and requires some initial experience.G-performance-projectGoal: For issues and PRs related to the Clippy Performance ProjectGoal: For issues and PRs related to the Clippy Performance Project
Type
Fields
Give feedbackNo fields configured for issues without a type.
Currently we have a ton of hardcoded paths for stdlib types.
Rustc has a way of tagging types for diagnostics via a "diagnostic item" API (rust-lang/rust#60966). We should go through rustc and tag most of these diagnostic items, and replace the hardcoded paths with hardcoded diagnostic item names instead. We can still keep the path framework around for rapid prototyping, but have a comment recommending people switch to diagnostic items whenever possible.