Repository navigation
Open
Labels
bugSomething isn't workingSomething isn't working
Description
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:
RuView/v2/crates/wifi-densepose-core/src/types.rs
Line 1426 in dd02efe
| .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.
Metadata
Metadata
Assignees
Labels
bugSomething isn't workingSomething isn't working
Activity
ruvnet commentedon Oct 2, 2026
core::fmt::Displayis available inno_stdenvironments — thecorecrate'sfmtmodule provides the same trait. Replacingstd::fmt::Displaywithcore::fmt::Display(or changing the import touse core::fmt) at the affected location would resolve this without needing a feature gate, which is the standard Rustno_stdcompatibility pattern.Generated by Claude Code
aepod commentedon Oct 2, 2026
Confirmed on main
03a89793:cargo check -p wifi-densepose-core --no-default-featuresfails with 80 errors. MEASURED, software-only, macOS native, rustc 1.89.0 (pinned toolchain), host target.The issue cites
std::fmt,std::cmpandstd::f64::consts. The failure is wider than that: most errors areString/Vecnot in scope, because thealloctypes aren't imported whenstdis off.E0412 cannot find type StringE0412 cannot find type VecE0433 unresolved module or unlinked crate stdE0433 undeclared type VecE0433 undeclared type StringBy file:
error.rs42,types.rs30,traits.rs7,utils.rs1. The crate declares#![cfg_attr(not(feature = "std"), no_std)]andextern crate alloc(lib.rs:43,47) withdefault = ["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.
danalec commentedon Oct 22, 2026
Confirmed and fixed. The crate declares
#![cfg_attr(not(feature = "std"), no_std)]and anextern crate alloc;, but its own code usedString,Vec,format!,ToStringandstd::fmt/std::cmp/std::f64::constspaths, so the configuration the declaration promises did not compile:80 errors across
error.rs(42),types.rs(30),traits.rs(7) andutils.rs(1).Why it was not caught
Feature unification. A workspace build unifies features across the members, and several depend on
wifi-densepose-corewith its default features, so the crate'sstdfeature comes back on even undercargo test --workspace --no-default-features:The
no_stdconfiguration was therefore never compiled.The fix
#2324 moves the allocating types to
allocand the formatting and comparison items tocore, and drops the cfg-gatedalloc_vecalias intraits.rs—alloc::vec::Vecandstd::vec::Vecare the same type, so the public signature ofCanonicalFrame::to_canonical_bytesis unchanged.extern crate alloc;becomes unconditional.CI now checks the
no_stdbuild of the crates that promise it, each on its own:wifi-densepose-bfldalready passed;wifi-densepose-coredid not.Verified: the
no_stdcheck, the default /serde/--all-featuresbuilds, the crate's 39 tests, clippy, andcargo check --workspace --no-default-featuresall pass. The gate fails on the pre-fix tree.