Custom target names containing bin lead to 'failed to parse the cfg from rustc --print=cfg' error

[phil-opp]

Steps to Reproduce

1. cargo new foo --lib and cd foo

2. Create file named custom-bin-target.json with the following content:

   {
       "llvm-target": "x86_64-unknown-none-gnu",
       "data-layout": "e-m:e-i64:64-f80:128-n8:16:32:64-S128",
       "arch": "x86_64",
       "target-endian": "little",
       "target-pointer-width": "64",
       "target-c-int-width": "32",
       "os": "none",
       "linker-flavor": "ld.lld",
       "linker": "rust-lld",
       "executables": true,
       "panic-strategy": "abort"
   }

3. Run cargo build --target custom-bin-target.json

The Error

The following error occurs:

error: failed to parse the cfg from `rustc --print=cfg`, got:
___
lib___.rlib
lib___.a
/home/philipp/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu
debug_assertions
proc_macro
target_arch="x86_64"
target_endian="little"
target_env=""
target_has_atomic="16"
target_has_atomic="32"
target_has_atomic="64"
target_has_atomic="8"
target_has_atomic="cas"
target_has_atomic="ptr"
target_os="none"
target_pointer_width="64"
target_vendor="unknown"


Caused by:
  unexpected character in cfg `/`, expected parens, a comma, an identifier, or a string

Debugging

When renaming the target file to custom-target.json, the error disappears. Renaming to a-b-c.json and target.json works too, but anything with the substring "bin" leads to the same error (e.g. bin.json or aabinoo.json). So the problem seems to be the substring "bin", but I have now idea why.

Versions

cargo 1.39.0-nightly (9655d70af 2019-09-10)
rustc 1.39.0-nightly (ca3766e2e 2019-09-14)

[ehuss]

This is a fairly simple parsing error caused by this line. Any unsupported crate type in the target name will cause a problem, since it is naively scanning through the error message:

warning: dropping unsupported crate type dylib for target custom-bin-target-6482127030478907173

The solution should be to parse the error a little more tightly.

[phil-opp]

@ehuss Thanks for the pointer! I opened #7364 to fix this.