return errors on unsupported targets (e.g., wasm)

[ForsakenHarmony]

error[E0433]: failed to resolve. Use of undeclared type or module `imp`
   --> C:\Users\harmony\.cargo\registry\src\github.com-1ecc6299db9ec823\same-file-1.0.3\src\lib.rs:105:19
    |
105 | pub struct Handle(imp::Handle);
    |                   ^^^ Use of undeclared type or module `imp`

version

nightly-x86_64-pc-windows-msvc (default)
rustc 1.30.0-nightly (39e6ba821 2018-08-25)

[BurntSushi]

Sorry, but I can't reproduce. cargo test on a checkout of this repository using rustc 1.30.0-nightly (39e6ba821 2018-08-25) works just fine.

The error message honestly just doesn't make any sense to me. Please provide more details. Is there something else about your environment that is unique? Have you tried using Rust stable? This library shouldn't have any differences between nightly and stable Rust.

[ForsakenHarmony]

Yeah it's weird to me too, I'm on windows just trying to update cargo-web via cargo install cargo-web --force

[BurntSushi]

Doesn't cargo-web do some sort of cross compilation for WASM? If so, then that is definitely relevant here, and should definitely be part of this bug report. I don't know how same-file should behave in a WASM environment, so I think someone more familiar with that target will need to chime in.

cc @alexcrichton You're the only one that comes to mind to ping on this... The relevant code is here:

same-file/src/lib.rs

Lines 78 to 86 in c499d02

	#[cfg(any(target_os = "redox", unix))]
	use unix as imp;
	#[cfg(windows)]
	use win as imp;
	#[cfg(any(target_os = "redox", unix))]
	mod unix;
	#[cfg(windows)]
	mod win;

which unstandable fails on WASM. What is the normal approach for things like this?

[ForsakenHarmony]

I don't think it's being compiled for wasm, just the cli tool

[alexcrichton]

@ForsakenHarmony do you perhaps have a .cargo/config setting the default build target to wasm? If set then it'll cause cargo install to install for the wasm target (which would lead to a failure like this)

[ForsakenHarmony]

Oh wow, I didn't think about that, that's probably it

Why does it read that with cargo install though?

[alexcrichton]

@ForsakenHarmony ah that's the subject of rust-lang/cargo#5874

[David-OConnor]

I'm getting this error when using the syntect crate as a dependency, and building to wasm32-unknown-unknown. Sounds like an incompatibility with the target

[BurntSushi]

@David-OConnor I don't know what the desired fix is supposed to be unfortunately.

[BurntSushi]

I don't think this should be re-opened. At least, I'm not convinced this is a problem in this crate. I don't even know what "same file" means in a wasm context.

[alexcrichton]

What is the normal approach for things like this?

Er sorry I never actually answered this original question, only the side effect! FWIW we generally try to get crates "working on wasm" which means they at least compile. The standard library just returns errors everywhere (files aren't a thing) but for crates.io-based crates you could either do that or just the crate (like winapi does on Unix for example).

[BurntSushi]

@alexcrichton Ah thanks for responding! Interesting! Making the crate just be empty would be easy I guess, but I imagine that would just push compilation errors up the chain. That is, you'd get this same problem, but just manifest in a different way. e.g., syntect is using same-file via walkdir, so syntect would need to avoid walking directories? Seems a little iffy, but I guess that's probably desired?

Returning errors seems OK too. Honestly, I'm not sure which way to go. I don't really have a strong opinion on what to do either way since I don't have much experience with how this sort of stuff is eventually handled at the application level.

[alexcrichton]

I'm personally partial to the "just return errors" route. While it feels wrong it's often the easiest to actually code against. A "correctly written" wasm app which is also portable to other platforms tends to be easiest to write (or at least so I find) when you can just have constant conditionals earlier in control flow to avoid these functions, but otherwise they look like they're still compiled in. I'm 100% certain others feel differently though :)

[BurntSushi]

Sounds good to me. Happy to defer to your judgment on this one!

[xmclark]

I am seeing a similar error with the relatively new wasi target on nightly 1.34. same-file has a bit more meaning for this target because it is for building wasm applications that can open files.

Steps to reproduce:

$ rustup target add wasm32-unknown-wasi --toolchain nightly
$ cargo +nightly build --target wasm32-unknown-wasi

[BurntSushi]

I'm personally unlikely to look into this any time soon. PRs for fixing this on other targets are welcome.

[autodidaddict]

I ran into this issue this morning and it's a showstopper for some work that I'm doing. This crate is in the dependency chain of quite a few things. If I try and compile my project for the wasm32-wasi target, in debug or release mode, I get the original errors reported at the beginning of this issue:

error[E0433]: failed to resolve: use of undeclared type or module `imp`
   --> /home/kevin/.cargo/registry/src/git.luolix.top-1ecc6299db9ec823/same-file-1.0.4/src/lib.rs:105:19
    |
105 | pub struct Handle(imp::Handle);
    |                   ^^^ use of undeclared type or module `imp`

It looks to me like the conditional attributes above the imports all fail under this target, so the imp import alias is never defined. In the WASI target, it needs to define the imp import alias.

[BurntSushi]

@autodidaddict Yes, as shown above, the issue is known.

This has been fixed in b121320 and put on to crates.io in same-file 1.0.5.