Fix file locking being not supported on Android raising an error#10975
Conversation
|
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @ehuss (or someone else) soon. Please see the contribution instructions for more information. |
| #[allow(unreachable_patterns)] | ||
| Some(libc::ENOTSUP | libc::EOPNOTSUPP) => true, | ||
| #[cfg(target_os = "linux")] | ||
| #[cfg(any(target_os = "linux", target_os = "android"))] |
There was a problem hiding this comment.
Looks reasonable. Though I don't know why treating Linux differently. It seems that Windows and macOS get that errno as well. ENOSYS is also a POSIX.1-2001 standard. #3666 added this specifically for Linux. Maybe we can blow the constraint away and treat all platform the same?
(just rumbling, not your fault)
There was a problem hiding this comment.
Yea, I think it should be safe to just remove the cfg. I did a scan, and the only targets that don't have ENOSYS are ones that Cargo doesn't run on AFAIK:
aarch64-apple-tvos
aarch64-nintendo-switch-freestanding
aarch64-unknown-hermit
aarch64-unknown-none
aarch64-unknown-none-softfloat
aarch64-unknown-uefi
armebv7r-none-eabi
armebv7r-none-eabihf
armv7a-none-eabi
armv7a-none-eabihf
armv7r-none-eabi
armv7r-none-eabihf
avr-unknown-gnu-atmega328
bpfeb-unknown-none
bpfel-unknown-none
i686-unknown-uefi
mipsel-sony-psp
mipsel-unknown-none
msp430-none-elf
nvptx64-nvidia-cuda
riscv32i-unknown-none-elf
riscv32im-unknown-none-elf
riscv32imac-unknown-none-elf
riscv32imac-unknown-xous-elf
riscv32imc-unknown-none-elf
riscv64gc-unknown-none-elf
riscv64imac-unknown-none-elf
thumbv4t-none-eabi
thumbv6m-none-eabi
thumbv7em-none-eabi
thumbv7em-none-eabihf
thumbv7m-none-eabi
thumbv8m.base-none-eabi
thumbv8m.main-none-eabi
thumbv8m.main-none-eabihf
wasm32-unknown-unknown
wasm64-unknown-unknown
x86_64-apple-tvos
x86_64-fortanix-unknown-sgx
x86_64-unknown-hermit
x86_64-unknown-none
x86_64-unknown-none-linuxkernel
x86_64-unknown-uefi
|
As we all agree on removing cfg, I am going to merge it. Thanks for @ehuss doing such an investigation and @theCapypara posting this PR. @bors r+ |
|
☀️ Test successful - checks-actions |
Update cargo 3 commits in efd4ca3dc0b89929dc8c5f5c023d25978d76cb61..9809f8ff33c2b998919fd0432c626f0f7323697a 2022-08-12 01:28:28 +0000 to 2022-08-16 22:10:06 +0000 - Improve error message for an array value in the manifest (rust-lang/cargo#10944) - Fix file locking being not supported on Android raising an error (rust-lang/cargo#10975) - Bump to 0.66.0, update changelog (rust-lang/cargo#10983)
Update cargo 3 commits in efd4ca3dc0b89929dc8c5f5c023d25978d76cb61..9809f8ff33c2b998919fd0432c626f0f7323697a 2022-08-12 01:28:28 +0000 to 2022-08-16 22:10:06 +0000 - Improve error message for an array value in the manifest (rust-lang/cargo#10944) - Fix file locking being not supported on Android raising an error (rust-lang/cargo#10975) - Bump to 0.66.0, update changelog (rust-lang/cargo#10983)
This PR fixes #10972 by not failing Cargo operations when the
target_osis Android and file locking is being reported as not being implemented by the kernel.I am sadly unable to actually test this at the moment, since despite my best efforts I am not able to get Cargo actually cross-compiled for Android (aarch64-linux-android).
I however don't see any reason why this wouldn't work.
target_osis "android" on Android and not "linux".