"Daniel Almeida" <daniel.almeida@collabora.com> writes:
>> On 6 Aug 2025, at 11:51, Andreas Hindborg <a.hindborg@kernel.org> wrote:
>>
>> "Daniel Almeida" <daniel.almeida@collabora.com> writes:
>>
>>>> On 11 Jul 2025, at 08:43, Andreas Hindborg <a.hindborg@kernel.org> wrote:
>>>>
>>>> Clean up the import statements in `gen_disk.rs` to make the code easier to
>>>> maintain.
>>>>
>>>> Reviewed-by: Alice Ryhl <aliceryhl@google.com>
>>>> Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
>>>> ---
>>>> rust/kernel/block/mq/gen_disk.rs | 10 +++++++---
>>>> 1 file changed, 7 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/rust/kernel/block/mq/gen_disk.rs b/rust/kernel/block/mq/gen_disk.rs
>>>> index cd54cd64ea88..679ee1bb2195 100644
>>>> --- a/rust/kernel/block/mq/gen_disk.rs
>>>> +++ b/rust/kernel/block/mq/gen_disk.rs
>>>> @@ -5,9 +5,13 @@
>>>> //! C header: [`include/linux/blkdev.h`](srctree/include/linux/blkdev.h)
>>>> //! C header: [`include/linux/blk_mq.h`](srctree/include/linux/blk_mq.h)
>>>>
>>>> -use crate::block::mq::{raw_writer::RawWriter, Operations, TagSet};
>>>> -use crate::{bindings, error::from_err_ptr, error::Result, sync::Arc};
>>>> -use crate::{error, static_lock_class};
>>>> +use crate::{
>>>> + bindings,
>>>> + block::mq::{raw_writer::RawWriter, Operations, TagSet},
>>>> + error::{self, from_err_ptr, Result},
>>>> + static_lock_class,
>>>> + sync::Arc,
>>>> +};
>>>> use core::fmt::{self, Write};
>>>>
>>>> /// A builder for [`GenDisk`].
>>>>
>>>> --
>>>> 2.47.2
>>>>
>>>>
>>>>
>>>
>>> Same comment as the preceding “import” patch: this is syntax is problematic.
>>
>> I used to share your viewpoint, but I changed my opinion and now prefer
>> "normalized" imports (the combined form).
>>
>> Now I can just blindly merge all the imports, remove duplicates and then
>> ask rust-analyzer to normalize imports again, and then format with
>> rustfmt. I find that this workflow is very low overhead.
>>
>>
>> Best regards,
>> Andreas Hindborg
>
> That’s because you have a separate commit where you do this before applying
> your work on top. If you’re rebasing on top of someone else's work, then a
> lot of conflicts will pop up. And unlike the saner approach where each import
> is in its own line, it’s now absolutely not clear how the conflicts should
> be resolved.
>
> The only thing that can be done then is to accept whatever the current change
> is, and ask rust-analyzer to reimport everything and reformat.
>
> IMHO, this is not great.
If we apply the normalized format everywhere, this will not be an issue.
Merging of imports can be almost automated. Just merge with strategy
keep all, and then normalize and remove duplicates.
Best regards,
Andreas Hindborg