Description
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";
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~