Non-ASCII Crate IDs do not work

[lilyball]

Right now we can create crates with non-ASCII names, and they compile just fine, but we can't seem to link against them. I've reproduced this problem on both OS X and Linux, so I'm pretty sure it's not a filename issue. It also doesn't seem to matter if the crate ID is using decomposed or composed characters (or characters that only have one form).

We already have a feature gate for non_ascii_idents, it seems reasonable that we should feature-gate having non-ascii crate IDs as well (both implicit IDs taken from the filename, and explicit ones specified with the attribute). I don't believe we need to test any clients of such crates (using the extern crate foo = "fℇℇ#0.0" syntax, as extern crate fℇℇ already hits non_ascii_idents) because using the crate is already broken, and fixing it will not have any compatibility issues.

Example:

foo.rs:

#![crate_id="fℇℇ#0.0"]
#![crate_type="rlib"]

pub fn foo() { println!("foo"); }

main.rs:

extern crate foo = "fℇℇ#0.0";

fn main() {
    foo::foo();
}

Compiling foo.rs works just fine, but compiling main.rs errors:

main.rs:1:1: 1:30 error: can't find crate for `foo`
main.rs:1 extern crate foo = "fℇℇ#0.0";
          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[lilyball]

Related to #2253.

[alexcrichton]

Hm, something funny with the encoding might be happening. I copy-and-pasted the code from this page and it worked on both OSX and linux. What's the output you get with RUST_LOG=rustc::metadata::loader?

[lilyball]

@alexcrichton My rustc is only 2 days old. I can try updating, but I didn't think there were any relevant changes recently.

That log provides nothing interesting. The very first reference to either "foo" or "fℇℇ" is the error

main.rs:1:1: 1:30 error: can't find crate for `foo`
main.rs:1 extern crate foo = "fℇℇ#0.0";
          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
error: aborting due to previous error

This is emitted immediately after it successfully reads libnative-83574243-0.11-pre.dylib.

[lilyball]

Aaand now I feel like a fool. I forgot -L .. Sigh.

Maybe rustc should suggest adding -L . if it can't find a crate, but the current directory contains a viable candidate?