Enable statx on all Linux targets and short-circuit it for musl

[Gelbpunkt]

This supersedes #154981. cc @strophy and sorry for taking a while to get around to this.

---

The first patch is the original PR with the commit message slightly adjusted, which makes use of the statx runtime detection on all Linux targets.

Since we want to unconditionally use statx on musl targets (because we know statx is available on our supported musl versions), we can call it through libc::statx. Making use of that requires telling the libc crate that we are on a musl version recent enough for it, which I decided to do in bootstrap. If there's a better place to set the environment variable, let me know, but this is the most straightforward way I could come up with.

With that in place, we can then wire up a short circuit to libc::statx for musl targets and skip the detection logic that all other Linux targets use.

On my aarch64-unknown-linux-musl machine, ./x.py test library/std still passes with these changes.

r? @tgross35 since I presume you have opinions on how I'm holding libc here

[rustbot]

tgross35 is currently at their maximum review capacity.
They may take a while to respond.

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[rust-log-analyzer]

The job x86_64-gnu-gcc failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)

test [ui] tests/ui/closures/move-closure-can-call-captured-fnmut.rs ... ok
test [ui] tests/ui/closures/module-path-not-confused-with-upvar.rs ... ok
##[error]The runner has received a shutdown signal. This can happen when the runner service is stopped, or a manually started runner is canceled.

Session terminated, killing shell...::group::Clock drift check
  local time: Sun Jul 19 01:37:30 UTC 2026
  network time: Sun, 19 Jul 2026 01:37:30 GMT
##[endgroup]
test [ui] tests/ui/closures/moved-upvar-mut-rebind-11958.rs ... ok
test [ui] tests/ui/closures/multiple-fn-bounds.rs ... ok

Important

For more information how to resolve CI failures of this job, visit this link.

[bjorn3]

This would break with build-std, right? Cargo wouldn't set this env var.

View changes since the review

[Gelbpunkt]

That's a good point, right. Not sure how to go about that. I presume we'd want to modify cargo to set the variable for rustc processes while compiling std? That sounds fairly complicated

[Mark-Simulacrum]

Can we make this a regular cargo feature prefixed with unstable or internal-do-not-use or something like that and then enable it here?

[Gelbpunkt]

More recent libc versions require us to specify --cfg=libc_unstable_musl_v1_2_3 as of rust-lang/libc@452750f, but in that case just setting it here still wouldn't be enough. Having to set this here and in cargo feels a bit hacky. It might make sense to make the rustc-dep-of-std feature imply libc_unstable_musl_v1_2_3. libc already suppresses a few warnings for musl version compatibility if that feature is enabled.

[tgross35]

Would we actually be able to lift the musl_v1_2_3 gate on statx? I don't remember why I originally asked for the gate but I guess maybe I was thinking of struct stat which has time_t fields (and thus would have an incorrect definition without musl_v1_2_3), whereas struct statx brings its own time types https://github.com/rust-lang/libc/blob/d0c9b0f14ef624576cfcb0a1285b2b29d54f4d47/src/unix/linux_like/mod.rs#L283-L333.

If we can do that then it avoids the build-std issue. At some point, however, we should probably figure out a way to set the cfgs for libc to enable 64-bit time_t.

[Gelbpunkt]

statx is supported in musl only since 1.2.5, so if libc were to unconditionally expose it, I presume you'd see linker errors with older musl releases when calling it. I really think the easiest path forward here would be making rustc-dep-of-std imply libc_unstable_musl_v1_2_3 and 64-bit time_t, that'd also fix the build-std issue.

[tgross35]

I don't think that's a problem since we have lots of API for all platforms that isn't available until more recently. Won't most users be getting musl via the bundled version anyway, which is 1.2.5?

Regardless I think what you mentioned with rustc-dep-of-std is reasonable, though it would be best to test it by first setting the cfg in rust-lang/rust and running tests to see if anything else needs changing (to avoid some back-and-forth)