Tracking Issue for Deprecate target_vendor

[pnkfelix]

This is a tracking issue for the MCP "Deprecate target_vendor" (rust-lang/lang-team#102).

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

Steps

• Implement the MCP (cc @rust-lang/lang -- there are solution sketches written out on Deprecate target_vendor  lang-team#102 (comment))
• Adjust documentation (see instructions on rustc-dev-guide)
• Stabilization PR (see instructions on rustc-dev-guide)

Unresolved Questions

• @scottmcm asked "What, technically, do you expect "deprecated" to mean here?"
• @thomcc wondered if adding more values to target_family might be problematic.

Implementation history

[workingjubilee]

With five "operating systems" (really, macOS, iOS, and different skins on iOS) released by Apple, we really ought to implement target_family = "apple" first. Either we can land that without destroying the ecosystem, or we need to reconsider this entire idea.

[thomcc]

target_family = "apple" first. Either we can land that without destroying the ecosystem...

Yeah, it's tricky to do this due to how much code does env::var("CARGO_CFG_TARGET_FAMILY").unwrap_or_default() == "unix" in build scripts as a way to detect unix (usually not verbatim, it's more common to see target family extracted, and then later matched on with arms for "unix" and "windows"). Technically this is already wrong, but only on a few fairly obscure targets (it also may not have been wrong when they wrote it, as target_family was initially single-valued).

It also can't be cratered, since crater tests only on Linux.

Edit: I've already said this, and it's even been linked to. Lmao.

[workingjubilee]

Yeah. I don't think people should be expected to gouge their eyes out maintaining "every time an Apple-based OS is involved, use target_os for each one instead of target_vendor for all of them, despite the fact that they use basically the same tech". Consider the publishing dates for the current set of Apple OS:

• 2001-03-24: macOS (FKA Mac OS X)
• 2007-06-29: iOS
• 2015-04-24: watchOS
• 2015-10-29: tvOS (or 2007 Jan, depending on who you ask)
• 2024-02-24: visionOS

It is entirely possible, at this rate, that we see another Apple OS released before the decade is out! ...But target_family = "apple" is equally fine.

We could consider cratering a different target_family that would affect Linux.