Add ENOTCAPABLE for macOS

[Thomasdezeeuw]

Description

Adds the ENOTCAPABLE constant. Also updates ELAST to 107 since a new error was added.

Sources

• https://github.com/apple-oss-distributions/xnu/blob/f6217f891ac0bb64f3d375211650a4c1ff8ca1ea/bsd/sys/errno.h#L267-L267

Checklist

• Relevant tests in libc-test/semver have been updated
• No placeholder or unstable values like *LAST or *MAX are
  included (see #3131)
• Tested locally (cd libc-test && cargo test --target mytarget);
  especially relevant for platforms that may not be checked in CI

@rustbot label +stable-nominated

[Thomasdezeeuw]

I was also wondering if ELAST should be deleted? But since it exists already it might be a breaking change?

[tgross35]

Needs updates given the CI failure.

Which macos version is xnu-12377.1.9? If it is MacOS 26, GHA should support that now, and you could send a PR bumping it. Otherwise you can add a skip in libc-test/build.rs, but the CI bump would be much preferred.

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[Thomasdezeeuw]

Push a commit to update the CI. One issue is that it doesn't seem that macOS 26 is supported on x86_64, so I didn't update the intel runner in

libc/.github/workflows/ci.yaml

Line 219 in df9237d

os: macos-15-intel

.

[Thomasdezeeuw]

With the update of macOS the CI now starts to fail:

 bad `HOST_VM_INFO64_COUNT` value at byte 0: rust: 38 (0x26) != c 40 (0x28)
    rust bytes: 26 00 00 00

    c bytes:    28 00 00 00

bad `vm_statistics64_data_t` size: rust: 152 != c 160
bad `vm_statistics64` size: rust: 152 != c 160
size of `vm_statistics64_data_t` is 160 in C and 152 in Rust
size of `struct vm_statistics64` is 160 in C and 152 in Rust

So we need #4926 as well, or ignore it somehow. I didn't see the HOST_VM_INFO64_COUNT failure locally oddly enough.

[JohnTitor]

I was also wondering if ELAST should be deleted? But since it exists already it might be a breaking change?

Yeah, it should be removed in 1.0.

So we only can add ENOTCAPABLE on 0.2 as any other things would be a breaking change, a solution here is moving things other than ENOTCAPABLE addiction (and test skip) to #4926, ship this on 0.2, then introduce breaking changes on 1.0 with #4926.

[tgross35]

Could you do the CI bump in a separate PR? To keep things that are required from that separate from new API.

[Thomasdezeeuw]

Could you do the CI bump in a separate PR?

That will mean the CI will fail, see my comment here: #4925 (comment). But I'm happy to do it.

[tgross35]

Yeah that's expected, bumping CI typically requires a few commits to update changed values like that. Getting that through before doing any brand new API just makes things simpler.