`unused_imports` shouldn't fire for `alloc` types included in the `std` prelude

[c410-f3r]

When working with libraries that can or can not be #[no_std], it is common to simply extern crate alloc; and then manually import types like alloc::vec::Vec. In this way everything works regardless of the configuration.

However, the latest versions of the compiler are warning such approach.

warning: the item Vec is imported redundantly
--> foo.rs:96:7
|
96 | use alloc::vec::Vec;
| ^^^^^^^^^^^^^^^
|
::: $HOME/.rustup/toolchains/nightly-2024-02-19-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/prelude/mod.rs:125:13
|
125 | pub use super::v1::*;
| --------- the item Vec is already defined here

In the above example, if use alloc::vec::Vec; is removed #[no_std] breaks. If not removed, the warning persists 😑

Maybe related: #121312 #121331 #121330 #120422

[kadiwa4]

Oftentimes, conditional no_std is done like this:

#![cfg_attr(not(feature = "std"), no_std)]

But if I understood your issue correctly, you can work around the warnings by instead doing:

#![no_std]

#[cfg(feature = "std")]
extern crate std;

Which consistently results in the std prelude not being used.

[c410-f3r]

#![no_std]

#[cfg(feature = "std")]
extern crate std;

Lol, what sorcery is this?

Is extern crate std canceling #[no_std] if std is activated?

[ChrisDenton]

#[no_std] prevents automatically linking in std. It doesn't stop you from doing so manually, which is what extern crate std does.

[MaxGraey]

#[no_std] prevents automatically linking in std

As I understand, no_std doing much more according to rust-embedded book:

[mumbleskates]

@MaxGraey Heap and collections are available if you have access to alloc, even in no_std. Availability of std in a no_std library is similarly possible; you just need to add it with extern crate std;.

"Stack overflow protection" and "runs init code before main" are properties of the whole binary and its main entrypoint, not of your specific library.

I believe it is actually better, and not less capable or meaningfully different, to write no_std-compatible libraries to be unconditionally #[no_std], then include extern crate std; by feature. This way the prelude will always be the same and these warnings will not fire because imports aren't redundant even when std support is enabled.

I can't judge whether the warnings are a regression, though.

[MaxGraey]

I still can't figure out how to implement graceful switching between "std" and "core" when "std" is optional for a working crate.

Previous solution was:

#![cfg_attr(not(feature = "std"), no_std)]

#[cfg(not(feature = "std"))]
extern crate alloc;

#[cfg(feature = "std")]
extern crate std as alloc;

If replace #![cfg_attr(not(feature = "std"), no_std)] to ![no_std] then you will need to use std::prelude::rust_2021::* explicitly, especially for macros like dbg!(...). All of this becomes difficult especially since std now overlaps with the core alias

[mumbleskates]

You shouldn't be using the std prelude in no_std, nor should you import std with the name alloc. Only import the features that only exist in std from that crate; import everything else directly from core or alloc.

You will have to write extra imports for things that are missing from the core prelude, like dbg!. In that particular case, because dbg! doesn't exist outside std, you could write an alternative that does nothing:

#[cfg(feature = "std")]
use std::dbg;
#[cfg(not(feature = "std"))]
use fallback_dbg as dbg;

#[allow(unused_macros)]
macro_rules! fallback_dbg {
    ($x:expr) => { $x };
};

[c410-f3r]

Maybe #116033 introduced this change?

The lint is acting as intended and @kadiwa4 provided an elegant workaround for library authors, as such, I will close this issue. If desired, feel free to open another issue to continue discussing the matter.