-
-
Notifications
You must be signed in to change notification settings - Fork 433
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
Portability fixes #1469
Portability fixes #1469
Conversation
Also assert that pointer width is an expected value.
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.
It may be worth to add a build-only CI job for a 16-bit target to prevent regressions in future.
@@ -10,10 +10,10 @@ | |||
|
|||
use rand_core::{RngCore, SeedableRng}; | |||
|
|||
#[cfg(any(target_pointer_width = "32", target_pointer_width = "16"))] |
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.
Why change it from not(target_pointer_width = "64")
? Even with hypothetical 128-bit targets it's better to use Xoshiro128++ than to break builds. Alternatively, it's worth to at least add a compile_error!
stating that we support only 16, 32, and 64 bit targets.
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.
- Because this is explicit about what is supported and recommended
- Effectively it is a compile error
- I don't care about theoretical targets. If people want to target 16- or 128-bits on rand, they can submit patches.
src/distributions/slice.rs
Outdated
#[cfg(feature = "alloc")] | ||
use alloc::string::String; | ||
|
||
#[cfg(not(any(target_pointer_width = "32", target_pointer_width = "64")))] | ||
const _: () = assert!(false, "unsupported pointer width"); |
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.
Why not use compile_error!
here? Also, why can't we use UniformSize::U32
on 16-bit targets?
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 forgot about it — I'll switch to
compile_error!
- Dependencies don't compile and it seems like no-one cares much about 16-bit (Supported target_pointer_width: 32, 64-bit only? #1468), so there's no point wasting time here.
enum UniformUsize { | ||
U32(Uniform<u32>), | ||
#[cfg(target_pointer_width = "64")] | ||
U64(Uniform<u64>), | ||
} |
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.
As with gen_index
, this should probably be exposed somehow (left for a future PR).
CHANGELOG.md
entrySummary
Fixes some of the smaller issues noted here. Specifically:
choose_multiple_array
rand::distributions::Slice
Further, this makes it more explicit which
target_pointer_width
sizesSmallRng
backends are intended to support (the 16-bit choice is not intended to be optimal).