Fixed issue #15192

[lkshayb]

Fixes #15192 by adding checks for no_std while giving out Box recommendation

changelog: [`large_enum_variant`]: Dont suggest `Box` in `no_std` mode

[rustbot]

r? @y21

rustbot has assigned @y21.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[github-actions]

Lintcheck changes for 0ef10a6

Lint	Added	Removed	Changed
clippy::large_enum_variant	0	0	13

This comment will be updated if you push new changes

[samueltardieu]

The changelog line in the PR description should contain the lint name in square brackets and quotes, such as in

changelog: [`large_enum_variant`]: do not suggest `Box` in `no_std` mode

(note also the quotes around Box and no_std)

This way it will be easily transformed into a link to the lint description when integrated in CHANGELOG.md when we issue the release notes.

[lkshayb]

@samueltardieu Thanks ! I've updated the changelog line as suggested .

[y21]

Hmm, I personally feel like the help message for what we're expecting the user to do to resolve the lint (introduce indirection for example by boxing) was still helpful as a hint.

Even in #![no_std] crates, one can still use extern crate alloc and use alloc::boxed::Box<_> that way (and I'd expect in practice this suggestion is very often still applicable), and even if the user doesn't have the alloc crate, I'd expect there would still be some other moral equivalent to introduce indirection

What do you think about instead of omitting this entirely in #![no_std] crates, actually "downgrade" the suggestion to just the help message, so it still hints to the user what they can do about it. We could also slightly change the message in case the user really can't use Box<_>. I'm thinking of something like:

help: consider boxing the large fields or introducing indirection in some other way to reduce the total size of the enum

[y21]

Tests are built as library crates, so you should be able to largely simplify this. The #![no_main] and panic handling code shouldn't be needed.

#![no_std]
#![warn(clippy::large_enum_variant)]

enum Myenum {
    //~^ ERROR: large size difference between variants
    Small(u8),
    Large([u8; 1024]),
}

[lkshayb]

@y21 Thanks for the feedback . You are correct that a downgraded help message should be used . I will update my pull request to follow the same and also I'll edit out the panic handler and #[no_main].

[lkshayb]

@y21 I have implemented the suggestions you made . Please review it now.

[lkshayb]

@rustbot r? @y21

[rustbot]

Requested reviewer is already assigned to this pull request.

Please choose another assignee.

[y21]

Can you also squash the commits into one?

[y21]

Is this if here on purpose? My suggestion was to always at least show the help message, no matter what, as a guidance in case the user has some other way to add indirection, even without access to alloc.

As is implemented right now, it will still suppress the help message entirely in #![no_std] (as can be seen in the test)

[y21]

Actually, looking at the git history on this branch, it looks like this was correct in lkshayb@0ac806d , but was then later reverted again in lkshayb@3e6d575

[lkshayb]

Thx @y21 for pointing this out . I've updated the pr now . and also squashed all the commits into one.

[lkshayb]

@y21 I've implemented the changes and squashed all the commits into one , please review now .