Rename RandomSource -> Rng, DefaultRandomSource -> SysRng

[joshtriplett]

Per naming bikeshed in libs-api. Rng is shorter, and already established in the ecosystem. Sys is also shorter, and makes it self-documenting that SysRng gets its randomness from the system RNG.

This also makes it short and convenient to write SysRng.fill_bytes, rather than DefaultRandomSource.fill_bytes.

[rustbot]

r? @jhpratt

rustbot has assigned @jhpratt.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: @ChrisDenton, libs
• @ChrisDenton, libs expanded to 11 candidates
• Random selection from LawnGnome, Mark-Simulacrum, aapoalas, clarfonthey, jhpratt

[rust-log-analyzer]

The job x86_64-gnu-tools failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)

...............................F.................. (50/144)
.................................................. (100/144)
............................................       (144/144)

======== tests/rustdoc-gui/go-to-collapsed-elem.goml ========

[ERROR] line 40
    at `tests/rustdoc-gui/go-to-collapsed-elem.goml` line 21: Error: Node is detached from document: for command `click: "//*[@id='search']//a[@href='../test_docs/struct.Foo.html#method.must_use']"`
    at <file:///checkout/obj/build/x86_64-unknown-linux-gnu/test/rustdoc-gui/doc/test_docs/struct.Foo.html?search=t_use>


<= doc-ui tests done: 143 succeeded, 1 failed, 0 filtered out

Error: ()

[hanna-kruppe]

Is SysRng still going to be "the default random source" (or: default RNG)? Discussion on Zulip raised two (possibly conflicting) reasons why we might want a DefaultRng separate from SysRng:

• On platforms where the raw system source has deficiencies that std can fix (e.g., non-uniform outputs), it may be useful to have the default source be distinct from SysRng so that the latter can remain a thin wrapper as advertised.
• On platforms where the raw system source is secure but slow, it's tempting to add a "faster, possibly not quite as secure, but fine for some uses" userspace PRNG and declare that one the default.

Conversely, if SysRng is still the default, then how do we make sure it's still perceived as the default if and when std::random gains a second or third type that implements Rng?

View changes since the review

[joshtriplett]

My intention was that SysRng is still the default, just named more concisely. I wasn't attempting to position it as something other than "default", hence why I didn't change any of these comments.

(I did see that discussion.)

Part of our rationale for keeping the system RNG as the default is that it's fast enough for most users, much faster on some platforms (e.g. Linux with vDSO), secure by default (on platforms where that's possible at all), and supports useful system properties like vmfork.

[jhpratt]

Looks like a simple change; r=me once CI is passing. Address the comment at your discretion.

[joboet]

I don't really want to bikeshed this all over again, but how about calling this SystemRng? We have precedent for System already: the System allocator and SystemTime, whereas the abbreviation isn't used anywhere else.

[joshtriplett]

@joboet SysRng has precedent in the ecosystem, but you're right that Sys doesn't have precedent in the standard library. Brevity is a virtue; so is precedent. Sigh.

[joshtriplett]

Looks like a simple change; r=me once CI is passing. Address the comment at your discretion.

I'm trying to figure out what the CI issue is. Currently re-running it because it's not clear to me if it's spurious or not.