Skip to content

Turn the core's std off, which the std feature could never do - #3

Merged
pathscale merged 1 commit into
masterfrom
fix/core-std-leak
Sep 7, 2026
Merged

pathscale merged 1 commit into
masterfrom
fix/core-std-leak

Conversation

@pathscale

Copy link
Copy Markdown
Owner

This crate exists to be parking_lot's Mutex and RwLock without std. It has not been that in any build.

The wrapper depends on parking_lot_lite_hack_core without default-features = false, and that core carries default = ["std"]. So the core linked std unconditionally, and this crate's std feature — the whole point — could not turn it off.

before, --no-default-features   parking_lot_lite_hack_core [default,std]
after,  --no-default-features   parking_lot_lite_hack_core []
after,  --features std          parking_lot_lite_hack_core [std]

One line: default-features = false on that dependency.

Why nothing caught it

no-std.yml is not wrong, it is half right. The lines naming the core directly were testing the real thing:

cargo test  -p parking_lot_lite_hack_core --no-default-features --lib   <- real
cargo check -p parking_lot_lite_hack_core --no-default-features         <- real

Every line that goes through the wrapper was not:

cargo check --no-default-features                          <- std core
cargo check --no-default-features --target ...windows-gnu  <- std core
cargo test  --no-default-features --test no_std_backends   <- std core

tests/no_std_backends.rs, the file whose name is the claim, was exercising a std core and passing for the wrong reason. Those same commands are now checking what they say.

Who this was breaking

WorkTablesIndex is being ported to no_std and takes this crate for its Mutex and RwLock. With the leak, WorkTablesIndex --no-default-features still pulled a std core, so its own no_std claim would have been false in a real build no matter what it did.

Checks

cargo test                           36 + 1 + 1 + 4 passed, 0 failed
cargo check --no-default-features    clean
cargo check                          clean
cargo fmt --check                    clean

Version 0.12.6. Publishing here is manual (release-plz is workflow_dispatch in this fork), so this needs a deliberate publish before WorkTablesIndex can require it.

The wrapper depended on `parking_lot_lite_hack_core` without
`default-features = false`, and that core has `default = ["std"]`. So the
core linked `std` in every build, and this crate's own `std` feature, which
exists to say otherwise, could not turn it off:

    before, --no-default-features   parking_lot_lite_hack_core [default,std]
    after,  --no-default-features   parking_lot_lite_hack_core []
    after,  --features std          parking_lot_lite_hack_core [std]

That makes the fork's own reason for existing untested. `no-std.yml` checks
the core directly with `-p ... --no-default-features`, and those lines were
real. Every line without `-p` went through this crate, so
`cargo check --no-default-features` and `--test no_std_backends` were
exercising a std core and passing for the wrong reason.

    cargo test                    36 + 1 + 1 + 4 passed
    cargo check --no-default-features   clean
    cargo check                         clean

0.12.6. Publishing here is manual, so the version bump is the only thing this
commit does about release.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant