Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
xobs opened this issue Dec 4, 2024 · 9 comments
Closed
Labels
C-discussion Category: Discussion or questions that doesn't represent real issues.

Comments

@xobs
Copy link
Contributor

xobs commented Dec 4, 2024

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
@xobs xobs added the C-bug Category: This is a bug. label Dec 4, 2024
@rustbot rustbot added the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Dec 4, 2024
@xobs
Copy link
Contributor Author

xobs commented Dec 4, 2024

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
$

@bjorn3
Copy link
Member

bjorn3 commented Dec 4, 2024

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

@xobs
Copy link
Contributor Author

xobs commented Dec 4, 2024

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$

@bjorn3
Copy link
Member

bjorn3 commented Dec 4, 2024

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)].)

@xobs
Copy link
Contributor Author

xobs commented Dec 5, 2024

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?

@jieyouxu jieyouxu added C-discussion Category: Discussion or questions that doesn't represent real issues. and removed C-bug Category: This is a bug. needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. labels Dec 5, 2024
@bjorn3
Copy link
Member

bjorn3 commented Dec 5, 2024

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;.

@xobs
Copy link
Contributor Author

xobs commented Dec 5, 2024

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.

@bjorn3
Copy link
Member

bjorn3 commented Dec 5, 2024

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.

@bjorn3 bjorn3 closed this as completed Dec 5, 2024
@bjorn3
Copy link
Member

bjorn3 commented Dec 8, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-discussion Category: Discussion or questions that doesn't represent real issues.
Projects
None yet
Development

No branches or pull requests

4 participants