Misleading error caused by incorrect target specification

[whitequark]

Using rustc 1.10.0-dev (cfcb716 2016-07-03), and the following specification (it's incomplete, but that's irrelevant):

{
  "llvm-target": "or1k-unknown-none",
  "target-endian": "little",
  "target-pointer-width": 32
}

This is the error I get:

error: internal compiler error: unexpected panic
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports
thread 'rustc' panicked at 'Field target-pointer-width in target specification is required', ../src/librustc_back/target/mod.rs:377
note: Run with `RUST_BACKTRACE=1` for a backtrace.

It's an ICE, which is a bit more scary than it ought to be, but that's fine. What's not fine is that it says there's no target-pointer-width but really what it doesn't like is that the value is not a string. Took me a while.

[cardoe]

This should likely improve with #34980.

[cardoe]

With #34980 (which is part of Rust 1.12.0) the error becomes:

$ rustc --target test.json
error: Error loading target specification: Field target-pointer-width in target specification is required
  |
  = help: Use `--print target-list` for a list of built-in targets

While its still not reporting that the field is present but of the wrong type I'm not sure if there's anything we can do to improve this while the compiler still uses rustc-serialize for its JSON handling.

[whitequark]

That's not really much better, as per my original report.

[cardoe]

Its at least not an ICE but instead a message saying it was unable to load the target specification. But like I said, you're correct that its incorrectly reporting the field missing when the actual issue is the data type is wrong.

[whitequark]

I have lost over a hour again due to this issue, now because "min-atomic-width": "32" is not valid and is silently ignored, whereas "min-atomic-width": 32 is valid. This is notwithstanding that "target-pointer-width": "32" is still the correct form. Consistency, who needs it?

[cardoe]

I recommend round tripping your config through --print target-spec-json. See #38338 for when its going to be available in stable.

[cardoe]

Worth noting that you currently have to do this on the nightly and append -Z unstable-options to the command line.

[japaric]

@whitequark Had a similar experience recently. I was wondering why this:

"pre-link-args": "-nostartfiles",

was not passing that argument to the linker. Turns out that the value has to be an array ...

The compiler should at least be printing warnings about this instead of simply ignoring the invalid values.

[Mark-Simulacrum]

Closing in favor of #24384.