The `TARGET` environment variable does not point to the file when a target JSON file is used

[shepmaster]

Steps

1. cargo new repro && cd repro

2. rustc +nightly -Z unstable-options --print target-spec-json --target x86_64-apple-darwin > x86_64-apple-darwin.json

   The JSON filename should match the target to avoid some strange cases in the compiler. This should occur on other platforms as well.

3. Create build.rs

   fn main() {
       dbg!(std::env::var("TARGET"));
   }

4. cargo +nightly build --target $PWD/x86_64-apple-darwin.json -Z build-std --verbose --verbose --verbose

   The build-std isn't really important to this issue, it's only used to support the non-standard target specification.

You'll see the TARGET variable no longer has the path and .json extension in the output:

[repro 0.1.0] [build.rs:2] std::env::var("TARGET") = Ok(
[repro 0.1.0]     "x86_64-apple-darwin",
[repro 0.1.0] )

This caused an issue in the rust-lang/rust repository while I was trying to port to aarch64-apple-darwin by using a JSON target file. Specifically, indexmap uses autocfg which uses TARGET to build things.

This was failing because my target didn't yet exist in the compiler, so autocfg decided it was the wrong version of rustc.

Possible Solution(s)

It seems like it should include the full path to the JSON file in the environment variable, but I'm not sure what the impact of such a change would be.

Notes

% cargo +nightly version
cargo 1.47.0-nightly (51b66125b 2020-08-19)

% rustc +nightly --version
rustc 1.47.0-nightly (5180f3da5 2020-08-23)

[ehuss]

I think this was a change caused by #7425, that was perhaps unintended (or at least unnoticed by me at the time). I am uncertain if @alexcrichton intentionally chose short_name here, or if it should be changed to rustc_target.

Considering that JSON specs are kinda unstable, and that is how TARGET used to behave prior to 1.40, I think there is some wiggle room to change it.

Since the short name can be inferred from the path (file_stem), then I think passing the full path is probably the best option. If something needs the short name for whatever reason (I can't immediately think of any), then it can be inferred from the path.

[cuviper]

Does the path need canonicalization? e.g. autocfg's working directory from a build script doesn't necessarily match the cargo invocation, right? I don't know, maybe that aspect is already covered in how it's normally passed to rustc.

[ehuss]

The path is canonicalized here. I think the canonicalized path is the right choice (except that canonicalize doesn't always work, but that's a separate issue).