Tracking Issue for Deprecate target_vendor

pnkfelix commented 2 years ago

This is a tracking issue for the MCP "Deprecate target_vendor" (https://github.com/rust-lang/lang-team/issues/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 https://github.com/rust-lang/lang-team/issues/102#issue-936041579)
[ ] 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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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.

workingjubilee commented 4 months ago

Switching from individual target_os to a single target_vendor appears to have revealed several bugs or OS-based variations without clear reasoning in the implementations of several Apple OS for libstd. I no longer believe this is a mere aesthetics or conciseness issue, it is about correctness.

workingjubilee commented 4 months ago

In https://github.com/rust-lang/rust/pull/124355 I ran the crater experiment I mentioned, and the trap did indeed get sprung! It has a number of regressions, but only 82 in total, and as usual, many of these source to a handful of crates.

I believe it may be possible to best-effort lint against this behavior. The arguments already advanced justify doing so:

It is already nonresilient due to prior decisions to make target_family an array
It is unfair to e.g. wasi to not be able to use these crates
It is unclear why we should not be able to add new target_family values going forward
There is definitely nothing stopping Windows from releasing "Windows on Wasm" or any other platform doing similar stuff to bring a plague on our head.

An alternative path forward is to persuade Cargo to change the env var they use, and to migrate everyone to the new behavior because they are relying on CARGO_CFG_TARGET_FAMILY working the way they currently expect. This seems strictly worse, as people will likely develop the habit of doing exact comparisons anyways inside their build scripts with the new env var, and we will be churning the entire damn ecosystem for no reason.

A final path forward, the path of least resistance, is, of course, to simply not deprecate target_vendor after all. However, I believe fixing these obstacles has other merits, so I don't really buy it.

sinkingsugar commented 2 months ago

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.

The ecosystem is already destroyed.. The amount of ninja patches to support some silly crates on visionos today is crazy... Not sure why this was not there from day 1.

rust-lang / rust