Use more std:: instead of core:: in docs for consistency

[poliorcetics]

@rustbot label T-doc

Some cleanup work to use std:: instead of core:: in docs as much as possible. This helps with terminology and consistency, especially for newcomers from other languages that have often heard of std to describe the standard library but not of core.

Edit: I also added more intra doc links when I saw the opportunity.

[rust-highfive]

r? @withoutboats

(rust-highfive has picked a reviewer for you, use r? to override)

[jyn514]

---- src/future/poll_fn.rs - future::poll_fn::poll_fn (line 12) stdout ----
error[E0432]: unresolved import `std::future::poll_fn`
 --> src/future/poll_fn.rs:15:5
  |
6 | use std::future::poll_fn;
  |     ^^^^^^^^^^^^^^^^^^^^ no `poll_fn` in `future`

I think this function might only be in core?

r=me once you get CI passing.

[poliorcetics]

It's only in core yes, but why ? unstable functions or not, shouldn't all pub items in core be reexported through std ?

[jyn514]

It should be, but it's not currently: #79174

[jyn514]

@bors r+ rollup

[bors]

📌 Commit 4eb76fc has been approved by jyn514

[therealprof]

It feels very weird to have doc examples in libcore which reference std. I appreciate this might confuse std users but there're also plenty of #[no_std] users out there who love a good and relevant example without being thrown off by the use of a library they can't use.

[poliorcetics]

It feels very weird to have doc examples in libcore which reference std.

This was already the case for the vast majority of the examples, this PR made it more consistent.

I also feel like no_std users are more "advanced" and certainly know to change std to core in their code.

There is also the problem that items in core are reexported in std so they end up with a documentation example on core::Something when they are looking at std::Something.

[therealprof]

I also feel like no_std users are more "advanced" and certainly know to change std to core in their code.

Not necessarily. With no_std becoming more popular due to wasm and embedded I totally expect that in the future even more people will jump in directly without knowing too much about the distinction.

There is also the problem that items in core are reexported in std so they end up with a documentation example on core::Something when they are looking at std::Something.

It would be great if there was a more general solution to properly handling re-exports, e.g. by rewriting re-exports automatically to the namespace at hand.

[poliorcetics]

due to wasm

True, I forgot about wasm.

It would be great if there was a more general solution to properly handling re-exports, e.g. by rewriting re-exports automatically to the namespace at hand.

Merging alloc/core and std is the optimal solution and it is often discussed but it cannot be done so easily. I'm not sure I would want rustdoc to change the code in examples too, it seems brittle.