indexmap-rs/indexmap

has_std is disabled on WSL

Closed this issue · 10 comments

rukai commented

I think you should just handle nostd like everyone else: default enabled std feature so we can opt out of std via default-features = false

bluss commented

Thanks for the report. Do you have any more info about how it works on WSL? Your conclusion is certainly likely given the problems we've had with this. Already on the 2.0 list.

rukai commented

No idea.
A friend was having issues with compiling a crate on wsl and we tracked it down to indexmap not having has_std enabled.

The precise error I had in WSL is this (compiling naga, which depends on indexmap):

error[E0107]: this struct takes 2 generic arguments but 1 generic argument was supplied
   --> /home/jay/.cargo/registry/src/github.com-1ecc6299db9ec823/naga-0.7.1/src/arena.rs:392:10
    |
392 |     set: IndexSet<T>,
    |          ^^^^^^^^ - supplied 1 generic argument
    |          |
    |          expected 2 generic arguments
    |
note: struct defined here, with 2 generic parameters: `T`, `S`
   --> /home/jay/.cargo/registry/src/github.com-1ecc6299db9ec823/indexmap-1.7.0/src/set.rs:67:12
    |
67  | pub struct IndexSet<T, S> {
    |            ^^^^^^^^ -  -
help: add missing generic argument
    |
392 |     set: IndexSet<T, S>,
    |                    +++

For more information about this error, try `rustc --explain E0107`.
error: could not compile `naga` due to previous error
warning: build failed, waiting for other jobs to finish...
error: build failed

The culprit is that I was building on the mountpoint for the host FS, which doesn't have write access by default:

[indexmap 1.7.0] error: could not copy "/mnt/c/Users/jay/projects/pixels/target/debug/build/indexmap-1683d57664f31640/out/probe0.probe0.3041c4be-cgu.0.rcgu.ll" to "/mnt/c/Users/jay/projects/pixels/target/debug/build/indexmap-1683d57664f31640/out/probe0.ll": Operation not permitted (os error 1)
[indexmap 1.7.0]
[indexmap 1.7.0] error: aborting due to previous error
[indexmap 1.7.0]
[indexmap 1.7.0] error: could not copy "/mnt/c/Users/jay/projects/pixels/target/debug/build/indexmap-1683d57664f31640/out/probe1.probe1.56ebf6f4-cgu.0.rcgu.ll" to "/mnt/c/Users/jay/projects/pixels/target/debug/build/indexmap-1683d57664f31640/out/probe1.ll": Operation not permitted (os error 1)
[indexmap 1.7.0]
[indexmap 1.7.0] error: aborting due to previous error
[indexmap 1.7.0]
[indexmap 1.7.0] warning: autocfg could not probe for `std`
[indexmap 1.7.0] error: could not copy "/mnt/c/Users/jay/projects/pixels/target/debug/build/indexmap-1683d57664f31640/out/probe2.probe2.a8400cd7-cgu.0.rcgu.ll" to "/mnt/c/Users/jay/projects/pixels/target/debug/build/indexmap-1683d57664f31640/out/probe2.ll": Operation not permitted (os error 1)
[indexmap 1.7.0]
[indexmap 1.7.0] error: aborting due to previous error
[indexmap 1.7.0]
[indexmap 1.7.0] cargo:rerun-if-changed=build.rs

This is output from the build script by cargo build -vv.

The culprit is that I was building on the mountpoint for the host FS, which doesn't have write access by default:

[indexmap 1.7.0] error: could not copy "/mnt/c/Users/jay/projects/pixels/target/debug/build/indexmap-1683d57664f31640/out/probe0.probe0.3041c4be-cgu.0.rcgu.ll" to "/mnt/c/Users/jay/projects/pixels/target/debug/build/indexmap-1683d57664f31640/out/probe0.ll": Operation not permitted (os error 1)

If it doesn't have write access, how did the temp *.rcgu.ll get written? Or even the compiled build script? Cargo is supposed to set a writable OUT_DIR environment variable, which autocfg uses for rustc --out-dir.

Got me... How did anything get written to allow most of the crate to build successfully?

I'm not sure if WSL is doing something magical with FS permissions or if there is a bug. Using the WSL VHD is much less problematic.

@parasyte the actual error you showed above is not necessarily related to how this crate detects std or no_std.

It just so happens I have submitted PR #207 that unifies the std and no_std API for IndexMap and IndexSet, which would solve your problems:

Also, FWIW the std/no_std detection works for me personally, but I do agree it'd be nice to have a typical std feature like most other crates offer.

We did add a std feature later. The historical problem is that we started with an assumption of using std, which means it would have worked even with default-features = false, which makes adding a no_std mode harder. Enter the detected has_std in #106, and then the forced std feature in #145, striving for backward compatibility the whole way.

Ah I missed that std feature. Either way, it works for me, so I have no qualms with how std detection is done. 👍

bluss commented

Duplicate of #184

I'll file this as a duplicate. On track for 2.0.