-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Move std::rand to a separate rand crate #12650
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
Conversation
@@ -63,12 +61,52 @@ pub fn next_test_port() -> u16 { | |||
} | |||
} | |||
|
|||
/// Create a random string of [a-z]'s. This makes no effort to be |
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.
This change is rather unfortunate, but this testing module seems to need to be built even in non-test configurations and so cannot depend on the rand crate.
I'm in favor of this. I have only one concern which is that so many other "very core" crates depend on this crate. Things like |
Addressed the |
It looks like the prelude didn't export random numbers. Is that right? I want to keep exploring this direction of pulling modules out of std, see how much we can separate these modules into crates, find out where the dependencies all are, but I do have reservations. We should reevaluate what cc @thestinger |
Yes, nothing from |
I love that you are thinking about using |
I'll answer @brson's commit comments here so they don't get lost when I rebase:
FWIW, we currently do display this info at the top right of pages (the
Well... so far our "feature removal path"/moving functions has been Nike deletion: "just do it". so in this case I'm doing a soft deletion, in that it has an error message to tell people what to use as a replacement (this came out of a discussion with @wycats where he said he had spent an inordinate amount of time trying to track down the new name of some silly little functions). Obviously, in this case, the leaving the body is super-easy & low cost, but in general it might be a little insane to keep the functionality intact: at this point in our library development we'd accumulate a pile of duplicated cruft (e.g. if the I'm happy to change it to just have the |
It looks like keeping the old behavior of r=me with a rebase. |
Added a new commit adding yet more "uniqueness" to the io::test hack. r? @alexcrichton (will rebase/squash later...) |
r=me |
This functionality is not super-core and so doesn't need to be included in std. It's possible that std may need rand (it does a little bit now, for io::test) in which case the functionality required could be moved to a secret hidden module and reexposed by librand. Unfortunately, using #[deprecated] here is hard: there's too much to mock to make it feasible, since we have to ensure that programs still typecheck to reach the linting phase.
This replaces it with a manual "task rng" using XorShift and a crappy seeding mechanism. Theoretically good enough for the purposes though (unique for tests).
This should be called far less than it is because it does expensive OS interactions and seeding of the internal RNG, `task_rng` amortises this cost. The main problem is the name is so short and suggestive. The direct equivalent is `StdRng::new`, which does precisely the same thing. The deprecation will make migrating away from the function easier.
Move std::rand to a separate rand crate This functionality is not super-core and so doesn't need to be included in std. It's possible that std may need rand (it does a little bit now, for io::test) in which case the functionality required could be moved to a secret hidden module and reexposed by librand. Unfortunately, using #[deprecated] here is hard: there's too much to mock to make it feasible, since we have to ensure that programs still typecheck to reach the linting phase. Also, deprecates/removes `rand::rng` (this time using `#[deprecated]`), since it's too easy to accidentally use inside a loop, making things very slow (have to read randomness from the OS and seed the RNG each time.)
fix: improve whitespace insertion in pretty printer Fixes rust-lang#12591 The `=>` token in the macro_rules! should be parsed as one fat arrow, but it ["requires a lot of changes in r-a"](rust-analyzer/ungrammar@143cc52), so I left it for the larger refactoring in the future and put a FIXME note.
fix false positive in Issue/12098 because lack of consideration of mutable caller fixes [Issue#12098](rust-lang/rust-clippy#12098) In issue#12098, the former code doesn't consider the caller for clone is mutable, and suggests to delete clone function. In this change, we first get the inner caller requests for clone, and if it's immutable, the following code will suggest deleting clone. If it's mutable, the loop will check whether a borrow check violation exists, if exists, the lint should not execute, and the function will directly return; otherwise, the following code will handle this. changelog: [`clippy::unnecessary_to_owned`]: fix false positive
Move std::rand to a separate rand crate
This functionality is not super-core and so doesn't need to be included
in std. It's possible that std may need rand (it does a little bit now,
for io::test) in which case the functionality required could be moved to
a secret hidden module and reexposed by librand.
Unfortunately, using #[deprecated] here is hard: there's too much to
mock to make it feasible, since we have to ensure that programs still
typecheck to reach the linting phase.
Also, deprecates/removes
rand::rng
(this time using#[deprecated]
), since it's too easy to accidentally use inside a loop, making things very slow (have to read randomness from the OS and seed the RNG each time.)