about summary refs log tree commit diff
path: root/src/test/run-pass/thinlto
diff options
context:
space:
mode:
authorCorey Farwell <coreyf@rwell.org>2017-03-19 10:18:21 -0400
committerGitHub <noreply@github.com>2017-03-19 10:18:21 -0400
commit9e11ecb7507b1d661a47346fe37da85eff548f67 (patch)
tree630eca52453a972d3fa3ebdfd05ca09bf4e1f8a5 /src/test/run-pass/thinlto
parentd8c8e01038eaf1d52c97af6aee7a6e7e03ad5c94 (diff)
parent2976ddbb1522397e3a9d91aa5ed9ae8e5cdbf97a (diff)
downloadrust-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