-
-
Notifications
You must be signed in to change notification settings - Fork 14.9k
Add allow-by-default lint when using item deprecated in the future #55892
Copy link
Copy link
Closed
Labels
E-easyCall for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.Call 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.Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion.
Metadata
Metadata
Assignees
Labels
E-easyCall for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.Call 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.Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion.
Type
Fields
Give feedbackNo fields configured for issues without a type.
With #30785 resolved, there now is a way to deprecate an item "for the future". It would be nice to be able to e.g. clean libstd from using such future-deprecated items and then to make sure that future PRs will not re-introduce new uses of that item again. I am thinking, for example, of when we will deprecate
mem::uninitializedin favor ofMaybeUninit: Once we got rid of all its uses in some crate here, we'll want to make sure people not aware of this deprecation do not accidentally reintroduce new uses ofmem::uninitializedin libstd.So maybe we could have an allow-by-default lint that libstd (and its dependencies) opt in to that complains about using items that are marked for future deprecation?