I did a crater run to compute the regressions that are still out there from RFC 1214. This converted RFC 1214 warnings into hard errors. It also took advantage of the cap-lints flag to try to better distinguish root failures from other failures: in particular, warnings were only converted to errors for the main crate being compiled. I think that this means that in principle we care about both root and non-root regressions, though the difference here is not large (and indeed the one non-root regression I investigated seemed to be a true non-root regression, where the error was from some other crate, I’m not sure why that is, perhaps my cap-lints code didn’t work properly). I haven’t really dug into the results in detail but the few spot checks I did looked mostly legit.
The interesting question then is what is the best strategy to go forward. There are still some bugs to fix related to RFC 1214, and we still have other soundness fixes to come (e.g., #25860). I have had the thought of trying to actively submit fixes to these projects to try and move things forward. I’m also not sure when the RFC 1214 work hit stable, I think perhaps just in this most recent release.
Another related problem that I noticed: the RFC 1214 warnings are hardcoded to be warnings because I didn’t want people to be able to suppress them without fixing the problem. But this also means that they can be overlooked! For example, I noticed a warning had appeared in rustc (turned out to be due to a bug), but we didn’t notice it because it only occurred in stage1/stage2, and since it was hard-coded to a warning, the #[deny(warnings)] flag that triggers in those stages didn’t cause it to be an error. One thing we might do to increase visibility of RFC 1214 warnings is to have them respect that flag.
Anyway, I see a few options:
- Switch the warnings to hard errors.
- Switch the warnings to hard errors, but include some way to temporarily revert them back to warnings if you opt-in. This mechanism would be removed in a future release.
- Switch the warnings to hard errors, unless the “cap-lints” option is in use (e.g., more-or-less what I tested). This would mean you get errors, but only for the project you are actively compiling.
- Leave them as warnings for now.
Somewhat orthogonally, we can choose to do active outreach to the affected projects:
- Simply send emails.
- Try and submit PRs or other fixes.