Skip to content
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 to 0.8 in library/ and compiler/ #89131

Closed
wants to merge 1 commit into from

Conversation

est31
Copy link
Member

@est31 est31 commented Sep 20, 2021

Removes some duplication. According to cargo tree, rand 0.7 is still used in various tools like miri, rls, or mdbook, but it's gone from library or compiler dependencies.

Removes some duplication.
@rust-highfive
Copy link
Collaborator

r? @Mark-Simulacrum

(rust-highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Sep 20, 2021
@klensy
Copy link
Contributor

klensy commented Sep 20, 2021

There was attempt in #86963, perhaps you will find similar target build issue.

@est31
Copy link
Member Author

est31 commented Sep 20, 2021

Good catch! Closing in favour of that PR.

@est31 est31 closed this Sep 20, 2021
@klensy
Copy link
Contributor

klensy commented Sep 20, 2021

Btw, if you knew how to fix PR for wasm target - i'm open for suggestions.

@est31
Copy link
Member Author

est31 commented Sep 21, 2021

@klensy first, apparently the error message has been improved in the 0.2.3 release. It suggests enabling the js feature. For this to work with cargo test however one needs to have a test runner that has a js environment around. I'm not sure which environment rustc uses.

Another alternative might be refactoring tests in core to disable getrandom usage from the rand crate, and then just use fixed seeds for testing.

bors added a commit to rust-lang-ci/rust that referenced this pull request Jan 8, 2023
…, 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`
thomcc pushed a commit to tcdi/postgrestd that referenced this pull request May 31, 2023
…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`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants