On Fri, 21 Mar 2025 at 07:16, Miguel Ojeda <miguel.ojeda.sando...@gmail.com> wrote: > > On Tue, Mar 18, 2025 at 9:02 AM David Gow <david...@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
smime.p7s
Description: S/MIME Cryptographic Signature
