-
-
Notifications
You must be signed in to change notification settings - Fork 15.4k
Enable statx on all Linux targets and short-circuit it for musl #159540
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
Gelbpunkt
wants to merge
3
commits into
rust-lang:main
Choose a base branch
from
Gelbpunkt:statx-musl
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
+76
−55
Open
Changes from all commits
Commits
Show all changes
3 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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?
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
More recent libc versions require us to specify
--cfg=libc_unstable_musl_v1_2_3as 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 therustc-dep-of-stdfeature implylibc_unstable_musl_v1_2_3. libc already suppresses a few warnings for musl version compatibility if that feature is enabled.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would we actually be able to lift the
musl_v1_2_3gate onstatx? I don't remember why I originally asked for the gate but I guess maybe I was thinking ofstruct statwhich hastime_tfields (and thus would have an incorrect definition withoutmusl_v1_2_3), whereasstruct statxbrings 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.Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
statxis 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 makingrustc-dep-of-stdimplylibc_unstable_musl_v1_2_3and 64-bit time_t, that'd also fix the build-std issue.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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-stdis 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)