On Fri, 21 Mar 2025 at 07:16, Miguel Ojeda miguel.ojeda.sandonis@gmail.com wrote:
On Tue, Mar 18, 2025 at 9:02 AM David Gow davidgow@google.com wrote:
In general, I think changes such as those in this series are going to get progressively more prone to conflicts as Rust is adopted by other subsystems, as the 'rust' tree won't be the only one carrying changes which could be affected. Maybe in the future it'd make sense to split these up into a series which enables the new feature, and only then put the warnings in place in the next version?
+1, I had to do a two-cycle split for other things in the past already, e.g. for Gary's FFI series.
I agree that churn for this kind of change has a cost. For tree-wide series, it will become harder and harder over time, just like in C, and some changes and cleanups may take several cycles.
For Clippy lints, I think we have some extra flexibility. We still aim to keep everything Clippy-clean (and patches sent should be sent clean under the latest stable Rust version at least, and maintainers should enable Clippy in their test runs), but if something slips in a particular corner/config/arch that is not routinely tested, it is not the end of the world as long as it gets cleaned up.
Sounds like the right sort of compromise to me: if we aim to have things be clean on the branches they're applied to, we can clean up any warnings which arise as a result of merging afterwards.
Anyway, KUnit `#[test]`s are in -- I was not planning to merge this now anyway, it should be reviewed a bit more.
Excellent! I'll make sure to review the new version of the patch when it's rebased.
Cheers, -- David