Skip to content

core::rand - adding task local lazily initialized rng, as per #3439 #3639

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

Closed
wants to merge 2 commits into from

Conversation

dbp
Copy link
Contributor

@dbp dbp commented Oct 2, 2012

This adds a task-local random number generator, seeded by the system, as per this issue: #3439. The intended use is like:

rand::task_rng().gen_int()

Though of course you could do:

let rng : Rng = rand::task_rng();
rng.shuffle(...);

@brson
Copy link
Contributor

brson commented Oct 2, 2012

Thanks! Merged. A single rand::random() -> uint function would be nice too.

@brson brson closed this Oct 2, 2012
bors added a commit to rust-lang-ci/rust that referenced this pull request Feb 13, 2023
… r=Veykril

Support generic function in `generate_function` assist

Part of rust-lang#3639

This PR adds support for generic function generation in `generate_function` assist. Now the assist looks for generic parameters and trait bounds in scope, filters out irrelevant ones, and generates new function with them.

See `fn_generic_params()` for the outline of the procedure, and see comments on `filter_unnecessary_bounds()` for criteria for filtering. I think it's good criteria for most cases, but I'm open to opinions and suggestions.

The diff is pretty big, but it should run in linear time w.r.t. the number of nodes we operate on and should be fast enough.

Some notes:
- When we generate function in an existing impl, generic parameters may cause name conflict. While we can detect the conflict and rename conflicting params, I didn't find it worthwhile mainly because it's really easy to resolve on IDE: use Rename functionality.
- I've implemented graph structure myself, because we don't have graph library as a dependency and we only need the simplest one.
  - Although `petgraph` is in our dependency graph and I was initially looking to use it, we don't actually depend on it AFAICT since it's only used in chalk's specialization graph handling, which we don't use. I'd be happy to replace my implementation with `petgraph` if it's okay to use it though.
- There are some caveats that I consider out of scope of this PR. See FIXME notes on added tests.
RalfJung pushed a commit to RalfJung/rust that referenced this pull request Jun 9, 2024
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.

2 participants