Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

validate target triples before resolving crates #33329

Closed
brson opened this issue May 2, 2016 · 1 comment · Fixed by #33363
Closed

validate target triples before resolving crates #33329

brson opened this issue May 2, 2016 · 1 comment · Fixed by #33363
Labels
A-diagnostics Area: Messages for errors, warnings, and lints

Comments

@brson
Copy link
Contributor

brson commented May 2, 2016

I stared at this for a while

$ rustc --target=x86_64_unknown-linux-musl src/main.rs
error: can't find crate for `std` [E0463]
error: aborting due to previous error

before realizing I had typod the target triple. If the target had been validated earlier the error would be more obvious.

@brson brson added the A-diagnostics Area: Messages for errors, warnings, and lints label May 2, 2016
@japaric
Copy link
Member

japaric commented May 2, 2016

So, I checked this and

If the target had been validated earlier the error would be more obvious.

we are already doing this. See:

$ rustc --target foo bar.rs
error: Error loading target specification: Could not find specification for target "foo"

i.e. validate the target before looking for crates.

The issue here is that x86_64_unknown-linux-musl (with underscore) is accepted as a valid target (as x86_64-unknown-linux-musl) because of this function -- it s/-/_/g the target name so it can compare it to the module name, which can't have dashes in it.

The fix seems simple because that function is defined in a macro and it also has access to the target names (the ones with dashes). So we have to tweak it to use that instead of the module names (the ones without dashes). I'll look into it.

japaric pushed a commit to japaric/rust that referenced this issue May 3, 2016
previously the logic was accepting wrong triples (like
`x86_64_unknown-linux-musl`) as valid ones (like `x86_64-unknown-linux-musl`) if
they contained an underscore instead of a dash.

fixes rust-lang#33329
bors added a commit that referenced this issue Jul 22, 2016
fix built-in target detection

previously the logic was accepting wrong triples (like
`x86_64_unknown-linux-musl`) as valid ones (like `x86_64-unknown-linux-musl`) if
they contained an underscore instead of a dash.

fixes #33329

---

r? @brson

I wanted to use a compile-fail test at first. But, you can't pass an extra `--target` flag to `rustc` for those because they already call `rustc --target $HOST` so you get a `error: Option 'target' given more than once.`. The run-make test used here works fine though.
bors added a commit that referenced this issue Jul 27, 2016
fix built-in target detection

previously the logic was accepting wrong triples (like
`x86_64_unknown-linux-musl`) as valid ones (like `x86_64-unknown-linux-musl`) if
they contained an underscore instead of a dash.

fixes #33329

---

r? @brson

I wanted to use a compile-fail test at first. But, you can't pass an extra `--target` flag to `rustc` for those because they already call `rustc --target $HOST` so you get a `error: Option 'target' given more than once.`. The run-make test used here works fine though.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-diagnostics Area: Messages for errors, warnings, and lints
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants