Handling Non-Negligible Impact Changes, Stabilization, and Removing a Lint

to at least notify the authors of affected crates the breaking change. If we can submit PRs to fix the problem, so much the better. #### Is it ever acceptable to go directly to issuing errors? Changes that are believed to have negligible impact can go directly to issuing an error. One rule of thumb would be to check against `crates.io`: if fewer than 10 **total** affected projects are found (**not** root errors), we can move straight to an error. In such cases, we should still make the "breaking change" page as before, and we should ensure that the error directs users to this page. In other words, everything should be the same except that users are getting an error, and not a warning. Moreover, we should submit PRs to the affected projects (ideally before the PR implementing the change lands in rustc). If the impact is not believed to be negligible (e.g., more than 10 crates are affected), then warnings are required (unless the compiler team agrees to grant a special exemption in some particular case). If implementing warnings is not feasible, then we should make an aggressive strategy of migrating crates before we land the change so as to lower the number of affected crates. Here are some techniques for approaching this scenario: 1. Issue warnings for subparts of the problem, and reserve the new errors for the smallest set of cases you can. 2. Try to give a very precise error message that suggests how to fix the problem and directs users to the tracking issue. 3. It may also make sense to layer the fix: - First, add warnings where possible and let those land before proceeding to issue errors. - Work with authors of affected crates to ensure that corrected versions are available _before_ the fix lands, so that downstream users can use them. ### Stabilization After a change is made, we will **stabilize** the change using the same process that we use for unstable features: - After a new release is made, we will go through the outstanding tracking issues corresponding to breaking changes and nominate some of them for **final comment period** (FCP). - The FCP for such issues lasts for one cycle. In the final week or two of the cycle, we will review comments and make a final determination: - Convert to error: the change should be made into a hard error. - Revert: we should remove the warning and continue to allow the older code to compile. - Defer: can't decide yet, wait longer, or try other strategies. Ideally, breaking changes should have landed on the **stable branch** of the compiler before they are finalized. <a id="guide"></a> ### Removing a lint Once we have decided to make a "future warning" into a hard error, we need a PR that removes the custom lint. As an example, here are the steps required to remove the `overlapping_inherent_impls` compatibility lint. First, convert the name of the lint to uppercase (`OVERLAPPING_INHERENT_IMPLS`) ripgrep through the source for that string. We will basically by converting each place where this lint name is mentioned (in the compiler, we use the upper-case name, and a macro

This section discusses strategies for handling breaking changes with a non-negligible impact, emphasizing the importance of warnings and migrating crates before landing changes. It details techniques such as issuing warnings for subparts of the problem and providing precise error messages. The section outlines the stabilization process, involving final comment periods and potential outcomes like converting to error, reverting, or deferring. Finally, it explains the steps to remove a custom lint once it's converted into a hard error.