On Wed, May 4, 2022 at 4:09 PM Miguel Ojeda <miguel.ojeda.sandonis@xxxxxxxxx> wrote: > > Hi Daniel, > > On Mon, May 2, 2022 at 9:44 PM Daniel Latypov <dlatypov@xxxxxxxxxx> wrote: > > > > Reviewed-by: Daniel Latypov <dlatypov@xxxxxxxxxx> > > > > Thanks for this, the code definitely should have been this way from the start. > > > > I had wanted to make this change but mistakenly thought the format > > func took it via non-const for some reason. > > I must have misread it once and got it into my head that we were > > leaving the door open for mutable child structs (which sounds like a > > bad idea). > > Thanks for reviewing it so quickly! Yeah, I was unsure too if there > was an external reason such as some future plan to use the mutability > as you mention or maybe some out-of-tree user was relying on it > already. > > But I thought it would be best to make it stricter until it is > actually needed (if ever); or if there is an actual user for > mutability, it should be documented/noted in-tree. I definitely agree here -- I can't recall any particular plan that would require this to be non-const, and we can always change it back if we really need to. > It also simplifies a tiny bit a Rust-side call to > `kunit_do_failed_assertion` that I am using within generated Rust > documentation tests. Very exciting! I assume that's the PR here: https://github.com/Rust-for-Linux/linux/pull/757 Cheers, -- David
