Can't imported aliased names in some circumstances

[unneon]

Describe the Bug

wasm-bindgen can sometimes deal with name conflicts, e.g. when two identically named items are imported from different modules. However, this behaviour does not trigger when importing items from two identically named namespaces from inside a module and outside it. I suggest to see the example for a better description.

Steps to Reproduce

1. Create a standard rust wasm library(lib.rs, crate-type, wasm-bindgen dependency).
2. Enter Rust code given below.
3. Rust wasm-pack build --target nodejs.

use wasm_bindgen::prelude::*;

#[wasm_bindgen(module = "fs")]
extern "C" {
	#[wasm_bindgen(js_namespace = window)]
	fn f1();
}

#[wasm_bindgen]
extern "C" {
	#[wasm_bindgen(js_namespace = window)]
	fn f2();
}

#[wasm_bindgen]
pub fn yoyo() {
	f1();
	f2();
}

Expected Behavior

The former import is correctly renamed so that both work. Naturally, require('fs').window.f1 does not exist and this fails at runtime, but it would work if there were appropriate node modules, omitted for the sake of brevity.

Actual Behavior

[INFO]: Checking for the Wasm target...
[INFO]: Compiling to Wasm...
    Finished release [optimized] target(s) in 0.01s
:-) [WARN]: origin crate has no README
error: failed to generate bindings for import `Value(Bare(JsImport { name: Global { name: "window" }, fields: ["f2"] }))`
    caused by: cannot import `window` from two locations
Error: Running the wasm-bindgen CLI
Caused by: failed to execute `wasm-bindgen`: exited with exit code: 1

Additional Context

I originally found the issue when porting a project. As of unneon/icie@e8f10b8, it can be also reproduced there by running wasm-pack build --target nodejs.

[alexcrichton]

Thanks for the report! The importing of JS items logic isn't the smartest right now and this shouldn't be too too hard to fix. I believe the fix is that we need to prioritize binding no-module imports before binding module imports, that way window imported from fs would be named something like window1 whereas the global window would remain untouched.