Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New lint: No longer supporting no_std use #940

Open
obi1kenobi opened this issue Sep 20, 2024 · 0 comments
Open

New lint: No longer supporting no_std use #940

obi1kenobi opened this issue Sep 20, 2024 · 0 comments
Labels
A-lint Area: new or existing lint

Comments

@obi1kenobi
Copy link
Owner

obi1kenobi commented Sep 20, 2024

Some crates (often on only some feature combinations) advertise support for no_std use cases: situations where the Rust standard library components (std, alloc, etc.) are not available and one can only use core.

It's relatively easy to accidentally break no_std support: for example, change an import from core to its equivalent std re-export, like we test for here: #892 (comment)

Users with no_std use cases would be broken by such a change. We may be able to lint for this after #638 is resolved. We should consider adding a lint for it then!

Such a lint would have more false-negatives unless rustdoc JSON starts including non-pub use statements when we --document-private-items. This is because a private item may import from std instead of core.

We'd also likely have to read source to make this work, not just rustdoc JSON. This is because rustdoc JSON normalizes import paths for foreign items, so std::fmt::Debug and core::fmt::Debug are both usually presented as core::fmt::Debug in rustdoc JSON.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-lint Area: new or existing lint
Projects
None yet
Development

No branches or pull requests

1 participant