-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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 deps #86963
Update rand deps #86963
Conversation
(rust-highfive has picked a reviewer for you, use r? to override) |
Should i add rand_core_0_6 here too?
There also rust-random/rand#1061:
|
Can you at least cite the changelogs for the updated crates? For example, the note about different results on big endian platforms may mean that we need to check our usage of those functions in the compiler, but it sounds like that investigation has not been done? Generally speaking updates to dependencies of the compiler or standard library that aren't just used in tests need some scrutiny for potential breakage caused by their new implementations and it's quite helpful if you provide a summary of what checking has been done (e.g., for each compatibility note in the crates' changelog, or similar listing). Alternatively, if it seems like the bump has no compatibility implications, then explicitly indicating that in the PR/commit description and why would also be helpful. |
Changes for rand 0.8 https://github.com/rust-random/rand/blob/master/CHANGELOG.md#080---2020-12-18 (this is for 0.8.0, description for up to 0.8.3 higher) Changes for rand_xorshift 0.3 https://github.com/rust-random/rngs/blob/master/rand_xorshift/CHANGELOG.md#030---2020-12-18 Existing tests that was broken by dependency update was fixed. There is only one place where rand used not for test (as far as i can see): rust/compiler/rustc_incremental/src/persist/fs.rs Lines 458 to 473 in 81053b9
and i don't see how this can broke anything, as we simply generate random number for folder name. |
Should i add something? |
@bors r+ rollup=iffy |
📌 Commit cf571e393f6a956a32ca15755fe6aee1f2ddbb6a has been approved by |
⌛ Testing commit cf571e393f6a956a32ca15755fe6aee1f2ddbb6a with merge a3199280041baacbdc2714b3307ac95fe6507ac8... |
This comment has been minimized.
This comment has been minimized.
💔 Test failed - checks-actions |
Ha-ha, actually breaks.
https://docs.rs/getrandom/0.2.3/getrandom/#webassembly-support
|
I don't have the bandwidth to investigate this failure and suggest a course of action for the wasm32 target; if you have a specific proposal, happy to review that though. |
⌛ Testing commit cf571e393f6a956a32ca15755fe6aee1f2ddbb6a with merge 074c72f8394e0632a1b263791642362f60f37125... |
I didn't changed anything yet, so it will fail for wasm again. |
This comment has been minimized.
This comment has been minimized.
💔 Test failed - checks-actions |
@bors r- For some reason this is in the queue again. |
Ping for triage: @klensy can you please post your status on this PR? |
rand_xorshift 0.2 -> 0.3
This comment has been minimized.
This comment has been minimized.
☔ The latest upstream changes (presumably #89545) made this pull request unmergeable. Please resolve the merge conflicts. |
Ping from triage: |
…, r=Mark-Simulacrum Update `rand` in the stdlib tests, and remove the `getrandom` feature from it. The main goal is actually removing `getrandom`, so that eventually we can allow running the stdlib test suite on tier3 targets which don't have `getrandom` 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 rust-lang#104095 and rust-lang#104185. Additionally, the fact that we can't update `rand`/`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 our `rand` dep, which definitely improves the status quo.~~ Checked and works now. 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` and `Location::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: - rust-lang#86963 (in particular rust-lang#86963 (comment) which explains why this is non-trivial) - rust-lang#89131 - rust-lang#96626 (comment) (I tried in that PR at the same time, but settled for just removing the usage of `thread_rng()` from the benchmarks, since that was the main goal). - rust-lang#104185 - Probably more. It's very tempting of a thing to "just update". r? `@Mark-Simulacrum`
…Simulacrum Update `rand` in the stdlib tests, and remove the `getrandom` feature from it. The main goal is actually removing `getrandom`, so that eventually we can allow running the stdlib test suite on tier3 targets which don't have `getrandom` 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 rust-lang/rust#104095 and rust-lang/rust#104185. Additionally, the fact that we can't update `rand`/`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 our `rand` dep, which definitely improves the status quo.~~ Checked and works now. 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` and `Location::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: - rust-lang/rust#86963 (in particular rust-lang/rust#86963 (comment) which explains why this is non-trivial) - rust-lang/rust#89131 - rust-lang/rust#96626 (comment) (I tried in that PR at the same time, but settled for just removing the usage of `thread_rng()` from the benchmarks, since that was the main goal). - rust-lang/rust#104185 - Probably more. It's very tempting of a thing to "just update". r? `@Mark-Simulacrum`
rand 0.7 -> 0.8
rand_xorshift 0.2 -> 0.3
This gives -6 crates for rustc compiler build