Lint to identify core symbols consumed through std

[d-e-s-o]

What it does

Personally, I think it would be helpful to have a lint that tells me that a symbol that I am using is available from the core crate, but I am importing it through std.

Categories (optional)

• Kind: probably clippy::pedantic

What is the advantage of the recommended code over the original code

In embedded development or whenever there may be a reason to have no_std compatibility in one form or another at some point, it is helpful to get an understanding of what is consumed from std, but really coming from core and could be used directly from there (and would not need to be feature gated, replaced, or whatever). Hence, having a lint that could highlight the use of re-exported core symbols through std would be useful, e.g., when no_std support is desirable at some point in the future, but perhaps not implemented right now.

Drawbacks

Not everyone may feel strongly about identifying core functionality as such and, in fact, in a good amount of cases there may not be any benefit to side-stepping std partly. But then it should be an optional feature, similar in nature to print_stdout, for example.

Example

use std::hash::Hasher;

Could be written as:

use core::hash::Hasher;

[d-e-s-o]

On that note, I'd be interested to hear if there is a good way to programmatically determine whether something is available from core without maintaining a list of all its symbols. I could envision invoking rustc on a file useing the symbol that is otherwise empty, but that seems kind of excessive. I am not sure Rust would allow for other introspection like this.

[camsteffen]

Very reasonable as a restriction lint. Name idea: std_instead_of_core.

[i509VCB]

On that note, I'd be interested to hear if there is a good way to programmatically determine whether something is available from core without maintaining a list of all its symbols. I could envision invoking rustc on a file useing the symbol that is otherwise empty, but that seems kind of excessive. I am not sure Rust would allow for other introspection like this.

Maybe if there were a way to programmatically get what crate a symbol belongs to? something like std_instead_of_alloc and alloc_instead_of_core as subset could make sense and that would require knowing what liballoc also provides.

[d-e-s-o]

Many thanks for getting these lints implemented, @i509VCB!