This one unused objc_exception dependency is preventing docs from building on docs.rs, because cc tries to pass -arch, to GCC, which doesn't see it as a valid argument, when building objc-exception.
Except, objc-exception doesn't really do anything in metal-rs. I grepped for all of the functions exported by objc-exception, and found nothing at all. I then ran
cargo check --target=x86_64-apple-darwin
cargo check --target=aarch64-apple-ios
cargo check --target=aarch64-apple-darwin
On both Windows and Linux and it passed with flying colours. To be sure, I checked the source of the objc crate crate, where the exception feature only brings in objc-exception and this catch_exception function. There are no special linkage parameters that objc_exception provides nor is it used at all by metal-rs and thus wgpu.
There's no reason to keep this around especially because its the only reason docs are breaking for it. It's causing trouble for downstream consumers of libraries that use wgpu, I've had to resort to workarounds like #[cfg(all(target_vendor = "apple", feature = "docsrs"))] to remove wgpu dependencies on my macOS docs build chain.
This one unused
objc_exception
dependency is preventing docs from building on docs.rs, becausecc
tries to pass-arch
, to GCC, which doesn't see it as a valid argument, when buildingobjc-exception
.Except,
objc-exception
doesn't really do anything in metal-rs. I grepped for all of the functions exported byobjc-exception
, and found nothing at all. I then rancargo check --target=x86_64-apple-darwin
cargo check --target=aarch64-apple-ios
cargo check --target=aarch64-apple-darwin
On both Windows and Linux and it passed with flying colours. To be sure, I checked the source of the
objc
crate crate, where theexception
feature only brings inobjc-exception
and thiscatch_exception
function. There are no special linkage parameters thatobjc_exception
provides nor is it used at all by metal-rs and thus wgpu.There's no reason to keep this around especially because its the only reason docs are breaking for it. It's causing trouble for downstream consumers of libraries that use wgpu, I've had to resort to workarounds like
#[cfg(all(target_vendor = "apple", feature = "docsrs"))]
to remove wgpu dependencies on my macOS docs build chain.This should fix https://github.com/gfx-rs/wgpu/issues/2956, https://github.com/gfx-rs/metal-rs/issues/5 , and obviate https://github.com/gfx-rs/metal-rs/pull/250
I've also fixed a
static_mut_ref
warning that cargo was complaining about.