Skip to content

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

Merged
merged 4 commits into from
Mar 12, 2014
Merged

Move std::rand to a separate rand crate #12650

merged 4 commits into from
Mar 12, 2014

Conversation

huonw
Copy link
Member

@huonw huonw commented Mar 2, 2014

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.)

@@ -63,12 +61,52 @@ pub fn next_test_port() -> u16 {
}
}

/// Create a random string of [a-z]'s. This makes no effort to be
Copy link
Member Author

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.

@alexcrichton
Copy link
Member

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 libgreen, libcollections, etc, seem like they should only depend on libstd. I don't think is that great of a concern, reducing the surface area of the standard library is probably best.

@huonw
Copy link
Member Author

huonw commented Mar 2, 2014

Addressed the io::test badness.

@brson
Copy link
Contributor

brson commented Mar 6, 2014

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 std actually means soon, because what it contains is right now driven mostly by technical concerns. We're moving away from having any standard library at all and at the end of this process what is left of std may be more like 'the runtime' (or maybe 'the prelude'), hopefully built on top of the more-or-less freestanding mini runtime.

cc @thestinger

@huonw
Copy link
Member Author

huonw commented Mar 6, 2014

Yes, nothing from std::rand was in the prelude (and it's been this way for as long as I can remember, so this isn't affect that behaviour in any significant manner).

@brson
Copy link
Contributor

brson commented Mar 6, 2014

I love that you are thinking about using #[deprecated] when refactoring libraries.

@huonw
Copy link
Member Author

huonw commented Mar 6, 2014

I'll answer @brson's commit comments here so they don't get lost when I rebase:

I wonder if we shouldn't leave the docs for deprecated functions. They can be styled in a way to discourage their use. [On the deletion of the docs from fn rng]

FWIW, we currently do display this info at the top right of pages (the unstable). It's not exactly obvious, though.

Can we leave the old behavior in the deprecated function (until we decide to remove it entirely)? Deprecated features need to provide a forward migration path; if the feature still works they can port at their leisure. [On replacing the body of fn rng with fail!]

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 std::util::swap etc. moves were done with deprecation, we'd have the code in two places; similarly for moving the intrinsics around).

I'm happy to change it to just have the #[deprecated].

@alexcrichton
Copy link
Member

It looks like keeping the old behavior of fn rng() isn't too hard in this case, so perhaps leaving it as-is (with the deprecated attribute) for now?

r=me with a rebase.

@huonw
Copy link
Member Author

huonw commented Mar 11, 2014

Added a new commit adding yet more "uniqueness" to the io::test hack. r? @alexcrichton (will rebase/squash later...)

@alexcrichton
Copy link
Member

r=me

huonw added 4 commits March 12, 2014 11:31
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.
bors added a commit that referenced this pull request Mar 12, 2014
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.)
@bors bors closed this Mar 12, 2014
@bors bors merged commit 689f197 into rust-lang:master Mar 12, 2014
@huonw huonw deleted the librand branch June 27, 2014 06:48
bors added a commit to rust-lang-ci/rust that referenced this pull request Jul 25, 2022
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.
flip1995 pushed a commit to flip1995/rust that referenced this pull request May 17, 2024
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants