csc for no_std and no_alloc crates

[xd009642]

Describe your use case

This will mainly focus on the no_alloc usecase!

In the embedded world (most typically), people rely on no_std crates where there's no standard library, no_std crates can still use alloc provided there's a global allocator for the platform or one provided. Then by adding an extern crate alloc or adding a dependency that uses alloc you can find your project doesn't compile for targets without a global allocator provided.

The motivating example from this is smoltcp where they added alloc accidentally and broke no_alloc builds (for anyone on a git dependency it wasn't published to crates.io):

• breakage: https://github.com/smoltcp-rs/smoltcp/commit/30966f3371301472a750ae8cf22135b48e7fee92
• fix: https://github.com/smoltcp-rs/smoltcp/commit/ee1a9e59ac9565f712b3b47a69cbc8f0412e27c3

The issue in question would be caused by just the addition of this line into the project extern crate alloc; which is fun.

Error message if you used the broken commit on a target with no default allocator:

error: no global memory allocator found but one is required; link to std or add `#[global_allocator]` to a static item that implements the GlobalAlloc trait

Describe the solution you'd like

In the perfect world rustdoc will be able to show you easily if a crate brings in alloc/core/std and if any features enable them. Then it would be in the rustdoc json (in theory) and you can write a nice trustfall query for it. But that requires changes at the rustdoc or compiler level so do with that what you will :eyes:

Alternatives, if applicable

Building a library with every single target and feature combination a user could use is also an approach, but is considered intractable given the number of targets rust supports.

Additional Context

There's some history of this causing issues or frustration for people and it being raised on the rust forum a few times:

• https://users.rust-lang.org/t/prohibit-accidental-alloc-crate-in-no-std/105076
• There is a clippy lint https://rust-lang.github.io/rust-clippy/rust-1.75.0/index.html#/alloc_instead_of_core

[obi1kenobi]

Great idea! To pull it off, we'll need more data than what rustdoc JSON currently provides. Currently, extern crate alloc; and use std::<stuff>; statements are not visible in rustdoc JSON, even with --document-private-items.

We'll need to either parse source code directly, or integrate with something like rust-analyzer.

There's a bunch of work to pull this off, though it's totally doable assuming we could find a funding source.

[xd009642]

Thought, could a cargo check run with no_std and no_alloc be done and see if it suddenly starts to fail to compile be an approach. I guess you need to pick a target that meets those and the user has installed so may be tricky :thinking:

[obi1kenobi]

Right — it would then probably be easier and more ergonomic for it to be implemented as a clever GitHub Action (for example) than as something cargo-semver-checks runs. That way it would run on the project's selected platform, say, immediately after the main test suite.