Error building libstd: with_hasher cannot be (indirectly) exposed to stable

As of yesterday's (2024-12-03) release of Rust, I am unable to build libstd for Xous:

$ RUST_COMPILER_RT_ROOT="$(pwd)/src/llvm-project/compiler-rt" \
        cargo +nightly \
        build --target riscv32imac-unknown-xous-elf 
        --manifest-path "library/sysroot/Cargo.toml"
   Compiling std v0.0.0 (/opt/Xous/rust-nightly/rust/library/std)
warning: dropping unsupported crate type `dylib` for target `riscv32imac-unknown-xous-elf`

error: `hashbrown::HashMap::<K, V, S>::with_hasher` cannot be (indirectly) exposed to stable
   --> std/src/collections/hash/map.rs:304:25
    |
304 |         HashMap { base: base::HashMap::with_hasher(hash_builder) }
    |                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = help: either mark the callee as `#[rustc_const_stable_indirect]`, or the caller as `#[rustc_const_unstable]`

error: `hashbrown::HashSet::<T, S>::with_hasher` cannot be (indirectly) exposed to stable
   --> std/src/collections/hash/set.rs:396:25
    |
396 |         HashSet { base: base::HashSet::with_hasher(hasher) }
    |                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = help: either mark the callee as `#[rustc_const_stable_indirect]`, or the caller as `#[rustc_const_unstable]`

warning: `std` (lib) generated 1 warning
error: could not compile `std` (lib) due to 2 previous errors; 1 warning emitted
$

Earlier versions did not have this error. Usually when this happens it's something Xous-specific, but in this case it looks like it's entirely within std::collections::hash.

Meta

rustc --version --verbose:

rustc 1.85.0-nightly (c44b3d50f 2024-12-03)
binary: rustc
commit-hash: c44b3d50fea96a3e0417e8264c16ea21a0a3fca2
commit-date: 2024-12-03
host: x86_64-unknown-linux-gnu
release: 1.85.0-nightly
LLVM version: 19.1.4

This also fails if I build it for the host target:

$ RUST_COMPILER_RT_ROOT="$(pwd)/src/llvm-project/compiler-rt" cargo +nightly build  --manifest-path "library/sysroot/Cargo.toml"
   Compiling compiler_builtins v0.1.138
   Compiling core v0.0.0 (/opt/Xous/rust-nightly/rust/library/core)
   Compiling libc v0.2.167
   Compiling std v0.0.0 (/opt/Xous/rust-nightly/rust/library/std)
   Compiling rustc-std-workspace-core v1.99.0 (/opt/Xous/rust-nightly/rust/library/rustc-std-workspace-core)
   Compiling alloc v0.0.0 (/opt/Xous/rust-nightly/rust/library/alloc)
   Compiling cfg-if v1.0.0
   Compiling rustc-demangle v0.1.24
   Compiling unwind v0.0.0 (/opt/Xous/rust-nightly/rust/library/unwind)
   Compiling rustc-std-workspace-alloc v1.99.0 (/opt/Xous/rust-nightly/rust/library/rustc-std-workspace-alloc)
   Compiling panic_unwind v0.0.0 (/opt/Xous/rust-nightly/rust/library/panic_unwind)
   Compiling panic_abort v0.0.0 (/opt/Xous/rust-nightly/rust/library/panic_abort)
   Compiling hashbrown v0.15.2
   Compiling std_detect v0.1.5 (/opt/Xous/rust-nightly/rust/library/stdarch/crates/std_detect)
error: `hashbrown::HashMap::<K, V, S>::with_hasher` cannot be (indirectly) exposed to stable
   --> std/src/collections/hash/map.rs:304:25
    |
304 |         HashMap { base: base::HashMap::with_hasher(hash_builder) }
    |                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = help: either mark the callee as `#[rustc_const_stable_indirect]`, or the caller as `#[rustc_const_unstable]`

error: `hashbrown::HashSet::<T, S>::with_hasher` cannot be (indirectly) exposed to stable
   --> std/src/collections/hash/set.rs:396:25
    |
396 |         HashSet { base: base::HashSet::with_hasher(hasher) }
    |                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = help: either mark the callee as `#[rustc_const_stable_indirect]`, or the caller as `#[rustc_const_unstable]`

error: could not compile `std` (lib) due to 2 previous errors
$

Just to make sure: You are building the standard library associated with the version of rustc with which you are building it?

Yes, that's what I'm doing:

user@ubuntu:/opt/Xous/rust-nightly/rust$ rustc +nightly --version
rustc 1.85.0-nightly (c44b3d50f 2024-12-03)
user@ubuntu:/opt/Xous/rust-nightly/rust$ git checkout c44b3d50f
HEAD is now at c44b3d50fea Auto merge of #133803 - matthiaskrgr:rollup-8ag5ncy, r=matthiaskrgr
user@ubuntu:/opt/Xous/rust-nightly/rust$ RUST_COMPILER_RT_ROOT="$(pwd)/src/llvm-project/compiler-rt" cargo +nightly build  --manifest-path "library/sysroot/Cargo.toml"
   Compiling std v0.0.0 (/opt/Xous/rust-nightly/rust/library/std)
error: `hashbrown::HashMap::<K, V, S>::with_hasher` cannot be (indirectly) exposed to stable
   --> std/src/collections/hash/map.rs:304:25
    |
304 |         HashMap { base: base::HashMap::with_hasher(hash_builder) }
    |                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = help: either mark the callee as `#[rustc_const_stable_indirect]`, or the caller as `#[rustc_const_unstable]`

error: `hashbrown::HashSet::<T, S>::with_hasher` cannot be (indirectly) exposed to stable
   --> std/src/collections/hash/set.rs:396:25
    |
396 |         HashSet { base: base::HashSet::with_hasher(hasher) }
    |                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = help: either mark the callee as `#[rustc_const_stable_indirect]`, or the caller as `#[rustc_const_unstable]`

error: could not compile `std` (lib) due to 2 previous errors
user@ubuntu:/opt/Xous/rust-nightly/rust$

Does it work if you add RUSTFLAGS="-Zforce-unstable-if-unmarked"? (Even if it doesn't fix this particular error, you should still pass that flag when building the standard library to ensure dependencies of the standard library can't be accessed by user code without #![feature(rustc_private)].)

Yes, that does solve the issue, thank you. I'll add it to future builds to ensure this doesn't happen again.

However, does this mean that with_hasher() is missing an "unstable" marker, which was caught by this?

base::HashSet and base::HashMap are coming from the hashbrown crate which can't mark anything as unstable as it can be compiled on stable too. It isn't necessary however as it is never directly re-exported by libstd (the code where the error shows up is a public wrapper around hashbrown) and -Zforce-unstable-if-unmarked prevents accessing libstd's hashbrown dependency through extern crate hashbrown;.

In that case, is there no error here? Curious how it was fine for years and it just became a problem.

If it's working as expected then I can close this issue.

In most cases you can call a function without a stability marker from a #[stable] or #[unstable] function. For const functions however we explicitly check that if the caller is #[stable] it only calls const functions which have been marked as allowing to be called directly or indirectly through stable functions to prevent accidentally exposing functionality to const fn's for which we haven't yet worked out the full implications (or for which we know it would cause problems) The exact way this gating is done has somewhat recently been reworked. Before this rework it likely accidentally was possible to call const functions without a stability marker and now it isn't anymore.

tl;dr: This is now working as expected and accidentally worked previously.

Looks like #133670 may make it work again without -Zforce-unstable-if-unmarked. That PR will be part of rust 1.85 which will be released February 20th. You should still use -Zforce-unstable-if-unmarked to ensure that user code can't access the dependencies of the standard library though.

rust: Upgrade 1.84.1->1.85.0

libstd-rs: Add rustflags RUSTFLAGS="-Zforce-unstable-if-unmarked"

rust: Upgrade 1.84.1->1.85.0

rustc: Add force unstable to hashbrown rules.mk

Navigation Menu

Repository navigation

Error building libstd: with_hasher cannot be (indirectly) exposed to stable #133857

Meta

19 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Error building libstd: with_hasher cannot be (indirectly) exposed to stable #133857

Description

Meta

Activity

xobs commented on Dec 4, 2024

bjorn3 commented on Dec 4, 2024

xobs commented on Dec 4, 2024

bjorn3 commented on Dec 4, 2024

xobs commented on Dec 5, 2024

bjorn3 commented on Dec 5, 2024

xobs commented on Dec 5, 2024

bjorn3 commented on Dec 5, 2024

bjorn3 commented on Dec 8, 2024

19 remaining items

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions