diff options
| author | Corey Farwell <coreyf@rwell.org> | 2017-03-19 10:18:21 -0400 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2017-03-19 10:18:21 -0400 |
| commit | 9e11ecb7507b1d661a47346fe37da85eff548f67 (patch) | |
| tree | 630eca52453a972d3fa3ebdfd05ca09bf4e1f8a5 /src/test/run-pass/thinlto | |
| parent | d8c8e01038eaf1d52c97af6aee7a6e7e03ad5c94 (diff) | |
| parent | 2976ddbb1522397e3a9d91aa5ed9ae8e5cdbf97a (diff) | |
| download | rust-9e11ecb7507b1d661a47346fe37da85eff548f67.tar.gz rust-9e11ecb7507b1d661a47346fe37da85eff548f67.zip | |
Rollup merge of #40621 - jswalden:dependant-spelling-fix, r=sfackler
Fix a spelling error in HashMap documentation, and slightly reword surrounding text for precision Noticed while reading docs just now. It's possible that the prior wording *meant* to state that the seed's randomness depends on the exact instant that the system RNG was created, I guess. But unless there's an API guarantee that this is the case, the wording seems over-precise. Is there a formal API guarantee that would forbid, say, the system RNG from generating all output using the Intel RDRAND instruction? I don't think the quality of output in that case would depend on when the RNG was created. Yet it seems to me like it could well be a valid source of randomness when computing the initial seed. For that reason, tying the randomness of the seed, to the quality of the RNG's output *at the precise instant the seed is computed*, seems less confining. That instantaneous quality level could be determined by the quality at the instant the RNG was created -- but instantaneous quality need not be low for that precise reason.
Diffstat (limited to 'src/test/run-pass/thinlto')
0 files changed, 0 insertions, 0 deletions
