Add visionos support

[guusw]

Add build support for VisionOS by adding the required feature checks. Note that vision is almost identical to iOS, except that the rust team decided to add a unique os feature "visionos"

Alternatives could be to check something like #[all(target_vendor = "apple", not(target_os = "macos"))]
to simplify all mobile devices, excluding desktop macos, let me know.

NOTE

A potential Issue it that the objc library does not have support for visionos and the library owned no longer seems to maintain the crate, we use a patched version in our project https://github.com/shards-lang/rust-objc/tree/shards-0.2.5
(based on this PR SSheldon/rust-objc#123)

I'm not sure what the preferred solution here would be:

• Using a patched crate vendored under gfx-rs org git url?
• Using a vendored copy of objc?

Checklist

• Run cargo fmt.
• Run taplo format.
• Run cargo clippy. If applicable, add:
  • --target wasm32-unknown-unknown
  • --target wasm32-unknown-emscripten
• Run cargo xtask test to run tests.
• Add change to CHANGELOG.md. See simple instructions inside file.

[nical]

A few cosmetic adjustments are needed to pass CI.

[ErichDonGubler]

The question of cargo fmt notwithstanding (@guusw: I wasn't able to push to this PR; did you check the checkbox to let maintainers edit this PR?), this sounds like a difficult PR to merge because of its dependencies. The OP's suggestions:

I'm not sure what the preferred solution here would be:

• Using a patched crate vendored under gfx-rs org git url?
• Using a vendored copy of objc?

…don't work for publishing to Crates.io (viz., cargo publish invocations will be blocked by validation that dependencies are also Crates.io crates). Unless we can get upstream to publish a new version with the PR that this is based on, I think we might have to rebase this on top of #5641, or use the alternative also in the OP:

Alternatives could be to check something like #[all(target_vendor = "apple", not(target_os = "macos"))]
to simplify all mobile devices, excluding desktop macos, let me know.

[nical]

I think we might have to rebase this on top of #5641

It seems to me that getting the cfg part to work and using a version of obj-c that supports the VisionOS are orthogonal, so I don't expect a rebase to be needed before merging this.

That said, looks like using target_vendor = "apple" might be cleaner than enumerating all of the apple devices to decide when to use metal. In most places we don't appear to differentiate between desktop and mobile.

[teoxoy]

It's worth noting that not all apple OSes support Metal.

[crowlKats]

Deno has no opinion on this change and is fine with the cargo.toml addition

[nical]

After some discussions on the matrix chat we concluded that we want to list the targets the way this PR does it. So once the CI errors are fixed, this should be good to land.

[jimblandy]

@guusw Could you look into the CI failures? These are MacOS failures so they do seem relevant.

[madsmtm]

Up to you of course, but I'd recommend #[cfg(target_vendor = "apple")] for all Metal stuff as that also includes tvOS (and any future OS Apple might release), #[cfg(all(target_vendor = "apple", not(target_os = "macos")))] for the places where you need to single out UIKit-specific stuff (or just #[cfg(not(target_os = "macos"))] if you're already within the context of the Metal backend), and #[cfg(target_os = "ios")] for truly iOS-specific stuff.

And sure sure, #[cfg(target_vendor = ...)] might be deprecated one day, but not before a suitable alternative such as #[cfg(target_family = "darwin")] is introduced.

If you really want, you could add something like the following to explicitly say that things won't compile on watchOS:

#[cfg(target_os = "watch")]
compile_error!("Metal, and by extension WGPU, does not work on watchOS");

[teoxoy]

I don't know what happens if you try to compile wgpu for watchos (it will probably work buy fail at runtime) but given that we already have cfg aliases I don't see why we shouldn't list the ones we explicitly want to support there.

[cwfitzgerald]

With apple's propensity to make new operating systems, I am inclined to just fully bucket it - just so don't have to maintain the list