Repository navigation
Regression affecting static-init versions 1.0.1-1.0.3: "failed to resolve: use of unresolved module or unlinked crate parking_lot" #150646
Description
[INFO] [stdout] error[E0433]: failed to resolve: use of unresolved module or unlinked crate `parking_lot`
[INFO] [stdout] --> /opt/rustwide/cargo-home/registry/src/index.crates.io-1949cf8c6b5b557f/static_init-1.0.3/src/lazy_sequentializer.rs:336:13
[INFO] [stdout] |
[INFO] [stdout] 336 | use parking_lot::lock_api::GetThreadId;
[INFO] [stdout] | ^^^^^^^^^^^ use of unresolved module or unlinked crate `parking_lot`
[INFO] [stdout] |
[INFO] [stdout] = help: if you wanted to use a crate named `parking_lot`, use `cargo add parking_lot` to add it to your `Cargo.toml`
[INFO] [stdout]
[INFO] [stdout]
[INFO] [stdout] error[E0433]: failed to resolve: use of unresolved module or unlinked crate `parking_lot`
[INFO] [stdout] --> /opt/rustwide/cargo-home/registry/src/index.crates.io-1949cf8c6b5b557f/static_init-1.0.3/src/lazy_sequentializer.rs:371:21
[INFO] [stdout] |
[INFO] [stdout] 371 | use parking_lot::lock_api::GetThreadId;
[INFO] [stdout] | ^^^^^^^^^^^ use of unresolved module or unlinked crate `parking_lot`
[INFO] [stdout] |
[INFO] [stdout] = help: if you wanted to use a crate named `parking_lot`, use `cargo add parking_lot` to add it to your `Cargo.toml`
[INFO] [stdout]
[INFO] [stdout]
[INFO] [stdout] error[E0433]: failed to resolve: use of unresolved module or unlinked crate `parking_lot`
[INFO] [stdout] --> /opt/rustwide/cargo-home/registry/src/index.crates.io-1949cf8c6b5b557f/static_init-1.0.3/src/lazy_sequentializer.rs:338:13
[INFO] [stdout] |
[INFO] [stdout] 338 | parking_lot::RawThreadId.nonzero_thread_id().into(),
[INFO] [stdout] | ^^^^^^^^^^^ use of unresolved module or unlinked crate `parking_lot`
[INFO] [stdout] |
[INFO] [stdout] = help: if you wanted to use a crate named `parking_lot`, use `cargo add parking_lot` to add it to your `Cargo.toml`
[INFO] [stdout]
[INFO] [stdout]
[INFO] [stdout] error[E0433]: failed to resolve: use of unresolved module or unlinked crate `parking_lot`
[INFO] [stdout] --> /opt/rustwide/cargo-home/registry/src/index.crates.io-1949cf8c6b5b557f/static_init-1.0.3/src/lazy_sequentializer.rs:372:26
[INFO] [stdout] |
[INFO] [stdout] 372 | if id == parking_lot::RawThreadId.nonzero_thread_id().into() {
[INFO] [stdout] | ^^^^^^^^^^^ use of unresolved module or unlinked crate `parking_lot`
[INFO] [stdout] |
[INFO] [stdout] = help: if you wanted to use a crate named `parking_lot`, use `cargo add parking_lot` to add it to your `Cargo.toml`
- https://crater-reports.s3.amazonaws.com/beta-1.93-4/beta-2025-12-22/reg/addr_of-0.1.4/log.txt
- https://crater-reports.s3.amazonaws.com/beta-1.93-4/beta-2025-12-22/reg/aerr-0.2.8/log.txt
- https://crater-reports.s3.amazonaws.com/beta-1.93-4/beta-2025-12-22/reg/async_wrap-0.1.10/log.txt
- Many others
This regression appears to affect the static-init crate versions 1.0.1-1.0.3, when built with debug_assertions on.
Explanation of the regression (Edit: This explanation is wrong), according to @cuviper, copied from zulip:
- static-init's feature "debug_order" enables parking-lot
- the code that uses it is gated on cfg(debug_mode) (not feature)
- the build script sets cfg "debug_mode" for feature "debug_order" or for debug_assertions, until 1.0.4 removed the latter
- thus it was trying to use parking-lot in all debug builds until 1.0.4 fixed that
and I think it's clearly the intention of #149273 that they shouldn't have been able to use parking-lot implicitly before
Activity
[-]Regression affecting `static-init` version 1.0.3 or earlier: "failed to resolve: use of unresolved module or unlinked crate `parking_lot`"[/-][+]Regression affecting `static-init` version 1.0.1-1.0.3: "failed to resolve: use of unresolved module or unlinked crate `parking_lot`"[/+][-]Regression affecting `static-init` version 1.0.1-1.0.3: "failed to resolve: use of unresolved module or unlinked crate `parking_lot`"[/-][+]Regression affecting `static-init` versions 1.0.1-1.0.3: "failed to resolve: use of unresolved module or unlinked crate `parking_lot`"[/+]apiraino commentedon Jan 3, 2026
bjorn3 commentedon Jan 3, 2026
theemathas commentedon Jan 3, 2026
(Note: The regression reproduces on Linux, but not Windows.)
Result of running
cargo bisect-rustc --start=1.92.0 --end=betaon an empty crate with a dependency ofstatic_init = "=1.0.3":Turns out that the regression actually occurred in #149199. Sorry for the confusion.
theemathas commentedon Jan 3, 2026
theemathas commentedon Jan 3, 2026
11 remaining items
theemathas commentedon Jan 7, 2026
To summarize the situation:
static-initversions 1.0.1-1.0.3 tried to detect if the crate was compiled withcfg(debug_assertions)on, and do conditional compilation based on that. However, the conditionally-compiled code had a bug: Ifcfg(debug_assertions)was detected to be on, code instatic-initwould attempt to importparking_lotwithout actually having it as a dependency.static-initversion 1.0.4static-initversions 1.0.1-1.0.3 were depending oncfg_aliasesversion 0.1 to check thecfgconditions. Thecfg_aliasescrate attempts to do this by checking if theCARGO_CFG_DEBUG_ASSERTIONSenv var was set.cfg_aliasesversion 0.2.0 starting also checking thePROFILEenv var in addition toCARGO_CFG_DEBUG_ASSERTIONSenv var, working around the bug below.debug_assertionssetting cargo#15760), cargo previously didn't set theCARGO_CFG_DEBUG_ASSERTIONSenv var in any situation. This causescfg_aliasesversion 0.1 to think thatcfg(debug_assertions)was not set. Which then causes bug instatic-initversions 1.0.1-1.0.3 to not happen.cfg_aliasesversion 0.1 to start correctly detectingcfg(debug_assertions), which triggered the bug instatic-initversions 1.0.1-1.0.3, which means thatstatic-initversions 1.0.1-1.0.3 will stop compiling in rust 1.93.0.chore: Update static_init (#40)
build(deps): update rust to v1.93.0
rust193: Add a package for rust 1.93.0.