-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Update rand
in the stdlib tests, and remove the getrandom
feature from it.
#104658
Conversation
Hey! It looks like you've submitted a new PR for the library teams! If this PR contains changes to any Examples of
|
Is the SmallRng seed's size really target-dependent? That's awful. |
I'll look into that and finish this up tomorrow. @rustbot author |
This comment has been minimized.
This comment has been minimized.
e495774
to
392b168
Compare
This comment has been minimized.
This comment has been minimized.
392b168
to
e8fb90b
Compare
This comment was marked as outdated.
This comment was marked as outdated.
e8fb90b
to
2a0b7f6
Compare
This seems to pass on all the targets I care to test on that would normally fail (most notably wasm32), which implies it really has excised So I don't think anything else is needed here, and it's ready for review. @rustbot ready |
If all goes well, maybe bump getrandom (https://github.com/rust-random/getrandom/blob/master/CHANGELOG.md#028---2022-10-20) too? |
I'll look into bumping |
It feels iffy to run randomized tests with fixed seeds. Can we conditionally import and use the getrandom feature on some tier-1 targets? |
Doing this conditionally would be more painful since I'd have to duplicate a body of a I guess I'll take a look at what it looks like though. |
As per #104658 (comment) I didn't end up going this route, but I have made it so that the places that were using non-determinism to improve testing are still using it. Avoiding copying the cursed function twice required moving a few of the tests inside liballoc's unit tests as a result. |
rand = "0.7" | ||
rand_xorshift = "0.2" | ||
rand = { version = "0.8.5", default-features = false } | ||
rand_xorshift = { version = "0.3.0", default-features = false } |
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.
25df61d
to
a4bf36e
Compare
@bors r+ rollup=iffy |
☀️ Test successful - checks-actions |
Finished benchmarking commit (2afe585): comparison URL. Overall result: ❌✅ regressions and improvements - no action needed@rustbot label: -perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)This benchmark run did not return any relevant results for this metric. CyclesThis benchmark run did not return any relevant results for this metric. |
Rustup Pulls in rust-lang/rust#104658
Rustup Pulls in rust-lang#104658
The main goal is actually removing
getrandom
, so that eventually we can allow running the stdlib test suite on tier3 targets which don't havegetrandom
support. Currently those targets can only run the subset of stdlib tests that exist in uitests, and (generally speaking), we prefer not to test libstd functionality in uitests, which came up recently in #104095 and #104185. Additionally, the fact that we can't updaterand
/getrandom
means we're stuck with the old set of tier3 targets, so can't test new ones.Anyway, I haven't checked that this actually does allow use on tier3 targets (I think it does not, as some work is needed in stdlib submodules) but it moves us slightly closer to this, and seems to allow at least finally updating ourChecked and works now.rand
dep, which definitely improves the status quo.For the most part, our tests and benchmarks are fine using hard-coded seeds. A couple tests seem to fail with this (stuff manipulating the environment expecting no collisions, for example), or become pointless (all inputs to a function become equivalent). In these cases I've done a (gross) dance (ab)using
RandomState
andLocation::caller()
for some extra "entropy".Trying to share that code seems way more painful than it's worth given that the duplication is a 7-line function, even if the lines are quite gross. (Keeping in mind that sharing it would require adding
rand
as a non-dev dep to std, and exposing a type from it publicly, all of which sounds truly awful, even if done behind a perma-unstable feature).See also some previous attempts:
rand::thread_rng
in the stdlib benchmarks. #96626 (comment) (I tried in that PR at the same time, but settled for just removing the usage ofthread_rng()
from the benchmarks, since that was the main goal).rand
to v0.8 in libstd #104185r? @Mark-Simulacrum