Supported target_pointer_width: 32, 64-bit only?

[dhardy]

All tier 1 and tier 2 platforms supported by Rust are 32- or 64-bit.

#1144 is the only issue I see regarding 16-bit support. Apparently this worked, but has been disabled since (#1269). Attempting to compile now:

$ rustc -V
rustc 1.81.0-nightly (24d2ac0b5 2024-07-15)

$ cargo build -Z build-std=core --target=avr-unknown-gnu-atmega328 --no-default-features
  Downloaded addr2line v0.22.0
  Downloaded gimli v0.29.0
  Downloaded object v0.36.0
  Downloaded 3 crates (636.7 KB) in 0.25s
   Compiling compiler_builtins v0.1.109
   Compiling core v0.0.0 (/home/dhardy-extra/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core)
error: ran out of registers during register allocation

   Compiling rustc-std-workspace-core v1.99.0 (/home/dhardy-extra/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/rustc-std-workspace-core)
error: could not compile `core` (lib) due to 1 previous error
warning: build failed, waiting for other jobs to finish...

$ cargo build -Z build-std=core --target=msp430-none-elf --no-default-features
   Compiling core v0.0.0 (/home/dhardy-extra/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core)
   Compiling compiler_builtins v0.1.109
   Compiling rustc-std-workspace-core v1.99.0 (/home/dhardy-extra/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/rustc-std-workspace-core)
   Compiling zerocopy v0.7.35
error[E0080]: evaluation of constant value failed
  --> /home/dhardy/.cargo/registry/src/index.crates.io-6f17d22bba15001f/zerocopy-0.7.35/src/macro_util.rs:69:21
   |
69 | const _64K: usize = 1 << 16;
   |                     ^^^^^^^ attempt to shift left by `16_i32`, which would overflow

error[E0080]: evaluation of constant value failed
   --> /home/dhardy/.cargo/registry/src/index.crates.io-6f17d22bba15001f/zerocopy-0.7.35/src/lib.rs:456:69
    |
456 |     const CURRENT_MAX_ALIGN: NonZeroUsize = match NonZeroUsize::new(1 << 28) {
    |                                                                     ^^^^^^^ attempt to shift left by `28_i32`, which would overflow

note: erroneous constant encountered
   --> /home/dhardy/.cargo/registry/src/index.crates.io-6f17d22bba15001f/zerocopy-0.7.35/src/lib.rs:575:47
    |
575 |             debug_assert!(self.align.get() <= DstLayout::CURRENT_MAX_ALIGN.get());
    |                                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

note: erroneous constant encountered
   --> /home/dhardy/.cargo/registry/src/index.crates.io-6f17d22bba15001f/zerocopy-0.7.35/src/lib.rs:576:48
    |
576 |             debug_assert!(field.align.get() <= DstLayout::CURRENT_MAX_ALIGN.get());
    |                                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

note: erroneous constant encountered
   --> /home/dhardy/.cargo/registry/src/index.crates.io-6f17d22bba15001f/zerocopy-0.7.35/src/lib.rs:578:52
    |
578 |                 debug_assert!(repr_packed.get() <= DstLayout::CURRENT_MAX_ALIGN.get());
    |                                                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

For more information about this error, try `rustc --explain E0080`.
error: could not compile `zerocopy` (lib) due to 2 previous errors

As far as I can tell, these are the only 16-bit Tier 3 targets, and the first fails to build the core library while zerocopy fails to build the second (@josephlr).

I don't see Rust support for any other pointer width.

---

Summary: our code can assume that the pointer width is 32 or 64 bits.

We should make this assumption explicit where code depends on this, e.g.:

#[cfg(not(any(target_pointer_width = "32", target_pointer_width = "64")))]
const _: () = assert!(false, "unsupported pointer width");

(I'm working on a related PR.)

If anyone wishes to revive 16-bit support, then first we need a functional test platform (including dependencies). It may make sense to limit support to a small subset of rand. It will be considered at best a second-class platform, and tests will be disabled if they become problematic again.

[dhardy]

Value-portability: we make some effort to make results like sequence shuffling reproducible across 32- and 64-bit platforms (for lists up to u32::MAX long). 16-bit platforms are excluded (and may skip value stability tests).

[jhpratt]

As a library author (for deranged specifically), this in combination with #1487 (ripping out isize entirely) are major pains. I am deliberately not making any decisions based on what I believe downstream users are doing, merely providing wrappers for range-bound integers. While I could conceivably work around isize and usize by calling the relevant methods gated by #[cfg], this remains impossible because rand refuses to compile on 16 bit platforms — something I want to support.

It seems to me that the primary rationale is a combination of the targets being tier 3 and making seeded randomness the same across platforms?

I'm not urging you to reconsider, but I do wish to express my frustration that these changes have brought about. Frankly, I'm seriously considering simply not supporting rand 0.9 because of it; it's not worth the hassle on my end.

[dhardy]

because rand refuses to compile on 16 bit platforms — something I want to support.

Is there some particular 16-bit target you want to support?

As far as I can tell, the only listed Rust target which is not 32- or 64-bit is AVR and this is stale and broken. The AVR-Rust appears to be abandoned.

And honestly, I'm not surprised. 16-bit targets are very memory constrained and Rust binaries are typically not that small, while the low complexity limit due to this memory constraint means that most of the advantages that a complex language like Rust has over C are lost. And 32-bit CPUs are cheap and ubiquitous today.

So is there actually a 16-bit target worth trying to support? (And can we have a CI test which at least builds for that target and isn't prone to breaking frequently?)

---

Regarding isize, I've already had a couple of PRs try to re-introduce this functionality. I might reconsider (given a valid actual use-case), but that's a new issue.

But, honestly, I'd suggest you simply drop support for StandardUniform on the RangedIsize type.

[jhpratt]

There is no particular platform that I wish to support beyond being able to do so in principle. I'm not an embedded nerd...Raspberry Pis are good enough for me.

Regarding isize and usize, the only thing I'd like it to do is its previous behavior, that being a random u16/32/64 as appropriate. Trying to shoehorn in it being used as an index, while notable for portability, seems somewhat odd given that every other primitive type uses the full range of values.

[dhardy]

There is no particular platform that I wish to support beyond being able to do so in principle.

I have no problem with supporting an actual target in principle, but from what I can tell there is no maintained 16-bit Rust target.