On Wed, May 4, 2022 at 4:09 PM Miguel Ojeda miguel.ojeda.sandonis@gmail.com wrote:
Hi Daniel,
On Mon, May 2, 2022 at 9:44 PM Daniel Latypov dlatypov@google.com wrote:
Reviewed-by: Daniel Latypov dlatypov@google.com
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