Skip to content

Conversation

@tarcieri
Copy link
Member

Via rustc itself:

expected values for `target_pointer_width` are: `16`, `32`, and `64`

This adds a doc(cfg(true)) attribute to the impls for isize and usize to hide the cfg gating so it doesn't show up in the rustdoc, but it's still retained to the crate compiles if rustc suddenly decides to add support for e.g. 8 or 128-bit wide pointers.

Via rustc itself:

    expected values for `target_pointer_width` are: `16`, `32`, and `64`

This adds a `doc(cfg(true))` attribute to the impls for `isize` and
`usize` to hide the `cfg` gating so it doesn't show up in the rustdoc,
but it's still retained to the crate compiles if rustc suddenly decides
to add support for e.g. `8` or `128`-bit wide pointers.
@tarcieri tarcieri merged commit 14621c5 into master Jan 18, 2026
22 checks passed
@tarcieri tarcieri deleted the cmov/mark-isize-usize-impls-as-always-available branch January 18, 2026 03:48
tarcieri added a commit that referenced this pull request Jan 18, 2026
From #1387, via rustc itself:

    expected values for `target_pointer_width` are: `16`, `32`, and `64`

So these impls should actually be ubiquitously available, for now.

If we remove the gating in this crate, then all we need to do to handle
new pointer widths is ship a fix for `cmov`.
tarcieri added a commit that referenced this pull request Jan 18, 2026
From #1387, via rustc itself:

    expected values for `target_pointer_width` are: `16`, `32`, and `64`

So these impls should actually be ubiquitously available, for now.

If we remove the gating in this crate, then all we need to do to handle
new pointer widths is ship a fix for `cmov`.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants