Skip to content

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

Open
Gelbpunkt wants to merge 3 commits into
rust-lang:mainfrom
Gelbpunkt:statx-musl
Open

Enable statx on all Linux targets and short-circuit it for musl#159540
Gelbpunkt wants to merge 3 commits into
rust-lang:mainfrom
Gelbpunkt:statx-musl

Conversation

@Gelbpunkt

@Gelbpunkt Gelbpunkt commented Jul 19, 2026

Copy link
Copy Markdown
Contributor

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 rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Jul 19, 2026
@rustbot

rustbot commented Jul 19, 2026

Copy link
Copy Markdown
Collaborator

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

@rustbot

This comment has been minimized.

@Gelbpunkt Gelbpunkt changed the title Statx musl Enable statx on all Linux targets and short-circuit it for musl Jul 19, 2026
strophy and others added 3 commits July 19, 2026 02:28
Since statx is currently invoked through the syscall directly anyways,
it makes no sense to gate it to glibc targets, since none of this is
glibc specific at the moment. As long as the kernel is recent enough, it
supports statx.
This is a requirement for using libc::statx in std and the musl baseline
in the Rust compiler is currently 1.2.5.
On musl targets, we can assume that musl has support for statx and falls
back to fstatat internally, so there's no need to do detection and
caching of statx in std.
@rustbot

rustbot commented Jul 19, 2026

Copy link
Copy Markdown
Collaborator

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

Copy link
Copy Markdown
Collaborator

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.

// default unless opted into via an environment variable. The version baseline of the Rust
// compiler targets is currently 1.2.5, so we can set the variable to get access to statx in
// std, amongst other things.
cargo.env("RUST_LIBC_UNSTABLE_MUSL_V1_2_3", "1");

@bjorn3 bjorn3 Jul 19, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

View changes since the review

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-libs Relevant to the library team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants