Skip to content

wifi-densepose-core uses std items without feature gate #2009

Open

Description

@the-shank

The wifi-densepose-core supports no_std conditionally:

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

However it uses std::fmt::Display without feature gate:

impl std::fmt::Display for FrameId {

impl std::fmt::Display for DeviceId {

It also uses std::fmt::Formatter without feature gate:

fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {

fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {

It also uses std::fmt::Result without feature gate:

fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {

fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {

It also uses std::cmp::Ordering without feature gate:

.unwrap_or(std::cmp::Ordering::Equal)

It also uses std::f64::consts::PI without feature gate:

let pi = std::f64::consts::PI;

let pi = std::f64::consts::PI;

This breaks no_std builds and prevents compilation on bare-metal or other no_std-only targets.

Activity

  1. ruvnet commented on Oct 2, 2026

    @ruvnet
    Owner

    core::fmt::Display is available in no_std environments — the core crate's fmt module provides the same trait. Replacing std::fmt::Display with core::fmt::Display (or changing the import to use core::fmt) at the affected location would resolve this without needing a feature gate, which is the standard Rust no_std compatibility pattern.


    Generated by Claude Code

  2. aepod commented on Oct 2, 2026

    @aepod
    Contributor

    Confirmed on main 03a89793: cargo check -p wifi-densepose-core --no-default-features fails with 80 errors. MEASURED, software-only, macOS native, rustc 1.89.0 (pinned toolchain), host target.

    The issue cites std::fmt, std::cmp and std::f64::consts. The failure is wider than that: most errors are String/Vec not in scope, because the alloc types aren't imported when std is off.

    cd v2 && cargo check -p wifi-densepose-core --no-default-features
    error: could not compile `wifi-densepose-core` (lib) due to 80 previous errors
    
    Error Count
    E0412 cannot find type String 44
    E0412 cannot find type Vec 20
    E0433 unresolved module or unlinked crate std 8
    E0433 undeclared type Vec 5
    E0433 undeclared type String 1

    By file: error.rs 42, types.rs 30, traits.rs 7, utils.rs 1. The crate declares #![cfg_attr(not(feature = "std"), no_std)] and extern crate alloc (lib.rs:43,47) with default = ["std"].

    #2018 applied on top of current main builds clean and the crate's tests pass (39 + 3 doctests). A CI job for the no-default build would keep it that way.

  3. danalec commented on Oct 22, 2026

    @danalec
    Contributor

    Confirmed and fixed. The crate declares #![cfg_attr(not(feature = "std"), no_std)] and an extern crate alloc;, but its own code used String, Vec, format!, ToString and std::fmt / std::cmp / std::f64::consts paths, so the configuration the declaration promises did not compile:

    $ cargo check -p wifi-densepose-core --no-default-features
    error: cannot find macro `format` in this scope
    error[E0425]: cannot find type `String` in this scope
    error[E0433]: cannot find module or crate `std` in this scope
    ...
    error: could not compile `wifi-densepose-core` (lib) due to 80 previous errors
    

    80 errors across error.rs (42), types.rs (30), traits.rs (7) and utils.rs (1).

    Why it was not caught

    Feature unification. A workspace build unifies features across the members, and several depend on wifi-densepose-core with its default features, so the crate's std feature comes back on even under cargo test --workspace --no-default-features:

    $ cargo tree --workspace -e features --no-default-features
    │   ├── wifi-densepose-core feature "default"
    │   │   └── wifi-densepose-core feature "std"
    

    The no_std configuration was therefore never compiled.

    The fix

    #2324 moves the allocating types to alloc and the formatting and comparison items to core, and drops the cfg-gated alloc_vec alias in traits.rs — alloc::vec::Vec and std::vec::Vec are the same type, so the public signature of CanonicalFrame::to_canonical_bytes is unchanged. extern crate alloc; becomes unconditional.

    CI now checks the no_std build of the crates that promise it, each on its own:

    - name: Check the no_std build of the crates that promise it
      working-directory: v2
      run: cargo check -p wifi-densepose-core -p wifi-densepose-bfld --no-default-features

    wifi-densepose-bfld already passed; wifi-densepose-core did not.

    Verified: the no_std check, the default / serde / --all-features builds, the crate's 39 tests, clippy, and cargo check --workspace --no-default-features all pass. The gate fails on the pre-fix tree.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions