Fix target_vendor for aarch64-nintendo-switch-freestanding

[madsmtm]

Previously set to target_vendor = "unknown", but Nintendo is clearly the vendor of the Switch, and is also reflected in the target name itself.

CC target maintainers @leo60228 and @jam1garner

[rustbot]

r? @chenyukang

rustbot has assigned @chenyukang.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rustbot]

These commits modify compiler targets.
(See the Target Tier Policy.)

[madsmtm]

Also, the "freestanding" part of the target triple is not reflected in either target_env nor target_abi, is this intentional? Or would it make sense to somehow expose that information to the user?

[jam1garner]

I don't see any reason why this change can't happen, I don't recall there being any specific intent in not specifying vendor

[leo60228]

aarch64-nintendo-switch-freestanding was renamed from aarch64-nintendo-switch late in the PR process, I think it was probably an oversight to not put it in target_env.

I don't remember if there was a reason target_vendor was unknown. I know we considered aarch64-unknown-horizon as another possible target name, but I didn't think that was ever implemented.

[madsmtm]

Thanks for the response both of you!

aarch64-nintendo-switch-freestanding was renamed from aarch64-nintendo-switch late in the PR process, I think it was probably an oversight to not put it in target_env.

I'll let the reviewing compiler team member @chenyukang decide whether it's an appropriate value in target_env.

[jieyouxu]

aarch64-nintendo-switch-freestanding is a Tier 3 target, and since both target maintainers agree:

• The target_vendor adjustments LGTM.
• I'm fine with changing target_env to be "freestanding", I don't see why this can't happen. EDIT: see below.

[madsmtm]

I'm fine with changing target_env to be "freestanding", I don't see why this can't happen.

Mostly because it's a new target_env that isn't used elsewhere in rustc, so it's setting precedent for that value in target_env.

[jieyouxu]

EDIT: Actually based on the reference https://doc.rust-lang.org/reference/conditional-compilation.html#target_env:

Key-value option set with further disambiguating information about the target platform with information about the ABI or libc used. For historical reasons, this value is only defined as not the empty-string when actually needed for disambiguation. Thus, for example, on many GNU platforms, this value will be empty. This value is similar to the fourth element of the platform’s target triple. One difference is that embedded ABIs such as gnueabihf will simply define target_env as "gnu".

Let's not include the target_env = "freestanding" change for now, as based on existing usage patterns it seems like it's more about the libc used: "gnu", "msvc", "musl", "sgx" etc. Specifically, I don't think we need this string for disambiguation yet, and we can always adjust this in the future if there's another target that needs disambiguation from the eixsting aarch64-nintendo-switch-freestanding target.

r=me after removing target_env changes, sorry for the confusion.

[madsmtm]

I'm more comfortable with that myself, too

[jieyouxu]

You can r=me after PR CI is green.

@bors delegate+ rollup

[bors]

✌️ @madsmtm, you can now approve this pull request!

If @jieyouxu told you to "r=me" after making some further change, please make that change, then do @bors r=@jieyouxu

[madsmtm]

@bors r=jieyouxu

[bors]

📌 Commit 746c322 has been approved by jieyouxu

It is now in the queue for this repository.