`vec_box` lint should not fire if the allocators between the `Vec` and `Box` are different

[repnop]

As the title suggests, now that there are custom allocators available to Box and Vec, the lint should take those into account when deciding to suggest vec_box. I hit this when I had a Vec<Box<MyType, MyTypeAllocator>> where it was not valid to use a Vec<MyType, MyTypeAllocator>.

Meta

• cargo clippy -V: clippy 0.1.53 (d0695c9 2021-04-12)
• rustc -Vv:

rustc 1.53.0-nightly (d0695c908 2021-04-12)
binary: rustc
commit-hash: d0695c9081b16077d0aed368bccaf437d77ff497
commit-date: 2021-04-12
host: x86_64-unknown-linux-gnu
release: 1.53.0-nightly
LLVM version: 12.0.0

[giraffate]

Thanks for the report!

Could you provide an example?

[repnop]

I've needed to change that particular bit since and leak the Boxes, so I don't have the code that I ran into it with, but the MyTypeAllocator is a private allocator for a hardware-layout defined type and isn't valid to use with Vec and co. as the allocations may not be contiguous in memory, hence the need for the Box and then using the Global allocator for the Vec to store those pointers in. I know its a bit of a weird example, but I imagine that I'm likely not the only one who will make non-general purpose allocators for specific use cases in which the allocator may only be valid for Box or some other types, so I don't think the lint is applicable any time the two allocators differ.

[camsteffen]

I don't have much experience with allocators, but I suspect that the lint is usually applicable even if the allocators differ (correct me if I'm wrong). And so I think this is a special case that you should #[allow].

[Jacherr]

Hi, I see this is marked as a good first issue and I'd love to get into the swing of contributing so I'll try and give this a go :)

Just to clarify - the intention for the #[allow] is to disable the lint in cases where the allocators differ?

@rustbot claim