Skip to content

crate: expose cfg for general 64-bit time_t functionality - #5411

Open
dybucc wants to merge 2 commits into
rust-lang:mainfrom
dybucc:time64-global-cfg
Open

crate: expose cfg for general 64-bit time_t functionality#5411
dybucc wants to merge 2 commits into
rust-lang:mainfrom
dybucc:time64-global-cfg

Conversation

@dybucc

@dybucc dybucc commented Aug 14, 2026

Copy link
Copy Markdown
Contributor

Description

This patch adds support for a new cfg that should allow easily
toggling support for 64-bit time_t in supported platforms. This
should make testing of this unstable feature flag in downstream crates
easier than having to manually set up the equivalent cfgs for any
one of linux_time_bits64, gnu_time_bits64 or uclibc_time64.

Note support for the equivalent flag in musl has not been included
because we already have set-up automatic detection and toggling of the
corresponding cfg under supported targets 1.

Checklist

  • Relevant tests in libc-test/semver have been updated
  • Commit messages permalink to headers for added or changed API
  • Placeholder or unstable values like *LAST or *MAX have the
    standard doc comment
  • Tested locally (cargo test -p libc-test --target mytarget);
    especially relevant for platforms that may not be checked in CI

@rustbot label +stable-nominated

Footnotes

  1. https://github.com/rust-lang/libc/blob/1a8e71f33b1d6ea1e072210e7fc994417bbb2e34/build.rs#L181-L190

@rustbot rustbot added S-waiting-on-review stable-nominated This PR should be considered for cherry-pick to libc's stable release branch labels Aug 14, 2026

@tgross35 tgross35 left a comment

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.

Could you also update CI to use this cfg rather than the current glibc/musl cfg? Since this is what we're most likely to ship, we should make sure it works.

View changes since this review

Comment thread build.rs Outdated
Comment on lines 187 to 196
@@ -190,7 +196,7 @@ fn main() {
}

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 should also set the musl_v1_2 flag, since that's pretty much all it's gating

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.

I don't think I understand. You mention the musl_v1_2 flag, but that
is already set in that particular code block. Further, you also mention
in another review comment that I shouldn't need the time64 flag, so I
don't think there's anything to change in this particular area.

Comment thread build.rs Outdated
Comment on lines +43 to +45
// Global flag to enable one of `linux_time_bits64` or `gnu_time_bits64`.
// The musl flags are enabled by default on supported platforms.
"time64",

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.

I think this isn't actually needed, this list is only for what gets sent to check-cfg and we won't use time64 directly (at least for now)

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.

Done.

@rustbot

rustbot commented Aug 25, 2026

Copy link
Copy Markdown
Collaborator

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

@dybucc
dybucc force-pushed the time64-global-cfg branch from 98e48b9 to 1ab4287 Compare August 29, 2026 06:37
@rustbot

This comment has been minimized.

@dybucc
dybucc force-pushed the time64-global-cfg branch from 1ab4287 to 01f4796 Compare August 29, 2026 07:18
@rustbot rustbot added the A-CI Area: CI-related items label Aug 29, 2026
@dybucc
dybucc force-pushed the time64-global-cfg branch from 4c3b4f1 to 1b1d2bb Compare August 29, 2026 09:53
@dybucc

dybucc commented Aug 29, 2026

Copy link
Copy Markdown
Contributor Author

I think it's done now. While checking through the CI workflow file, I
noticed that we even though we set the "updated but deprecated"
RUST_LIBC_UNSTABLE_MUSL_V1_2 environment variable for certain targets
1, we still check for RUSTC_LIBC_UNSTABLE_MUSL_V1_2_3 in build.rs
2.

I was wondering what's our stance on that change for stable releases,
and whether we should even set the deprecated environment variable in
CI. It seems wrong.

@rustbot ready

Footnotes

  1. https://github.com/rust-lang/libc/blob/75b2850150d0c50fa012ce965b7466d46da8e4e3/.github/workflows/ci.yaml#L223

  2. https://github.com/rust-lang/libc/blob/75b2850150d0c50fa012ce965b7466d46da8e4e3/build.rs#L162-L164

@rustbot

rustbot commented Aug 30, 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.

dybucc added 2 commits August 30, 2026 16:10
Add `cfg` enabling `time64` functionality across all supported targets.
This ensures users have a simple entry point to the crate functionality
gated behind one of `linux_time_bits64`, `uclibc_time64` and
`gnu_time_bits64`.
Switch as many uses of other target-specific `cfg`s with the `time64`
`cfg` introduced in the prior patch.
@dybucc
dybucc force-pushed the time64-global-cfg branch from a89083f to 36137bc Compare August 30, 2026 14:10
@rustbot

rustbot commented Aug 31, 2026

Copy link
Copy Markdown
Collaborator

☔ The latest upstream changes (possibly #5313) made this pull request unmergeable. Please resolve the merge conflicts.

@tgross35 tgross35 left a comment

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.

Two small things then LGTM

View changes since this review

Comment thread .github/workflows/ci.yaml
Comment on lines 388 to +402
steps:
- uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
with:
persist-credentials: false
- run: |
msrv="$(
cargo metadata --format-version 1 |
jq -r --arg CRATE_NAME ctest '.packages | map(select((.name == $CRATE_NAME) and (.id | startswith("path+file")))) | first | .rust_version'
)"
echo "MSRV: $msrv"
echo "MSRV=$msrv" >> "$GITHUB_ENV"
- name: Install Rust
run: rustup update "$MSRV" --no-self-update && rustup default "$MSRV"
- uses: Swatinem/rust-cache@6323deb102c322ba6fcbdcafc7e3dddab59af2b6 # v2.9.2
- run: cargo build -p ctest
- uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
with:
persist-credentials: false
- run: |
msrv="$(
cargo metadata --format-version 1 |
jq -r --arg CRATE_NAME ctest '.packages | map(select((.name == $CRATE_NAME) and (.id | startswith("path+file")))) | first | .rust_version'
)"
echo "MSRV: $msrv"
echo "MSRV=$msrv" >> "$GITHUB_ENV"
- name: Install Rust
run: rustup update "$MSRV" --no-self-update && rustup default "$MSRV"
- uses: Swatinem/rust-cache@6323deb102c322ba6fcbdcafc7e3dddab59af2b6 # v2.9.2
- run: cargo build -p ctest

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.

It's fine to reformat this if it makes things more consistent, but please put it in a separate commit

Comment thread ci/verify-build.py
if "musl" in target_env:
# Check with breaking changes from musl, including 64-bit time_t on 32-bit
run(cmd, rustflags=f"{rustflags} --cfg=libc_unstable_musl_v1_2")
if "gnu" in target_env and target_bits == "32" or "musl" in target_env:

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.

Use parens to make the order of operations clear

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

Labels

A-CI Area: CI-related items S-waiting-on-author stable-nominated This PR should be considered for cherry-pick to libc's stable release branch

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants