This does not suggest adding such a function to the public API. This is
just for the purpose of avoiding duplicate code. Many array methods
already contained the same kind of code and there are still many array
related methods to come (e.g. `Iterator::{chunks, map_windows, next_n,
...}`) which all basically need this functionality. Writing custom
`unsafe` code for each of those seems not like a good idea.

This file contained a lot of repetitive code.  This was about to get
considerably worse, with introduction of a slew of new aliases.

No functional change.  I've eyeballed the docs and they don't seem to
have changed either.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

I'm pretty sure I am going want this for rust-lang#73125 and it seems like an
omission that would be in any case good to remedy.

It's a shame we don't have competent token pasting and case mangling
for use in macro_rules!.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

…escriptions

Fixes rust-lang#82283

Before:

    The Rust Standard LibraryThe Rust Standard Library is the foundation of portable Rust software, a set of minimal and battle-tested shared abstractions for the broader Rust ecosystem. It offers core types, like `Vec<T>` and `Option<T>`, library-defined operations on language primitives, standard macros, I/O and multithreading, among many other things.

After:

    The Rust Standard Library

This code wasn't actually working, and trying to SEO optimize that page is pointless anyway.

…would always return Some(thing)

…nge() which would always return Ok(..)

…_copy_from_cache_work_item (always returns Ok(..))

…sic()

Co-authored-by: Joshua Nelson <joshua@yottadb.com>

Co-authored-by: Joshua Nelson <joshua@yottadb.com>

…) and rustc_allow_const_fn_unstable()

Enums on hexagon use a smallest size (but at least 1 byte) that fits all
the enumeration values. This is unlike many other ABIs where enums are
at least 32 bits.

…ray, r=dtolnay

Add internal `collect_into_array[_unchecked]` to remove duplicate code

Unlike the similar PRs  rust-lang#69985, rust-lang#75644 and rust-lang#79659, this PR only adds private functions and does not propose any new public API. The change is just for the purpose of avoiding duplicate code.

Many array methods already contained the same kind of code and there are still many array related methods to come (e.g. `Iterator::{chunks, map_windows, next_n, ...}`, `[T; N]::{cloned, copied, ...}`, ...) which all basically need this functionality. Writing custom `unsafe` code for each of those doesn't seem like a good idea. I added two functions in this PR (and not just the `unsafe` version) because I already know that I need the `Option`-returning version for `Iterator::map_windows`.

This is closely related to rust-lang#81615. I think that all options listed in that issue can be implemented using the function added in this PR. The only instance where `collect_array_into` might not be general enough is when the caller want to handle incomplete arrays manually. Currently, if `iter` yields fewer than `N` items, `None` is returned and the already yielded items are dropped. But as this is just a private function, it can be made more general in future PRs.

And while this was not the goal, this seems to lead to better assembly for `array::map`: https://rust.godbolt.org/z/75qKTa (CC ``@JulianKnodt)``

Let me know what you think :)

CC ``@matklad`` ``@bstrie``

Provide NonZero_c_* integers

I'm pretty sure I am going want this for rust-lang#73125 and it seems like an
omission that would be in any case good to remedy.

<strike>Because the raw C types are in `std`, not `core`, to achieve this we
must export the relevant macros from `core` so that `std` can use
them.  That's done with a new `num_internals` perma-unstable feature.

The macros need to take more parameters for the module to get the
types from and feature attributes to use.

I have eyeballed the docs output for core, to check that my changes to
these macros have made no difference to the core docs output.</strike>

…enkov

Make "missing field" error message more natural

```rust
struct A {
    x: i32,
    y: i32,
    z: i32,
}

fn main() {
    A { };
}
```
```
error[E0063]: missing fields `x`, `y`, `z` in initializer of `A`
 --> src/main.rs:8:5
  |
8 |     A { };
  |     ^ missing `x`, `y`, `z`
```
This error is now:
```
error[E0063]: missing fields `x`, `y` and `z` in initializer of `A`
 --> src/main.rs:8:5
  |
8 |     A { };
  |     ^ missing `x`, `y` and `z`
```
I thought it looked nicer and more natural this way. Also, if there is >3 fields missing, there is an "and" as well ("missing \`x\`, \`y\`, \`z\` *and* 1 other field"), but for <=3 there is not. As such it improves consistency too.

As for the implementation, originally I ended up with a chunky `push_str` algorithm but then I figured I could just do the formatting manually since it's just 3 field names at maximum. It is comparatively readable.

As a sidenote, one thing I was wondering about is, isn't there more cases where you have a list of things like field names? Maybe this whole thing can at some point later be made into a more general function to be used in multiple areas.

…jyn514

Use the first paragraph, instead of cookie-cutter text, for rustdoc descriptions

Partially addresses rust-lang#82283.

…yn514

rustdoc: Remove unnecessary `Cell` around `param_env`

r? `@jyn514`

remove redundant option/result wrapping of return values

If a function always returns `Ok(something)`, we can return `something` directly and remove the corresponding error handling in the callers.
clippy::unnecessary_wraps

improve UnsafeCell docs

Sometimes [questions like this come up](https://rust-lang.zulipchat.com/#narrow/stream/136281-t-lang.2Fwg-unsafe-code-guidelines/topic/UnsafeCells.20as.20raw.20pointers) because the UnsafeCell docs say "it's the only legal way to obtain aliasable data that is considered mutable". That is not entirely correct, since raw pointers also provide that option. So I propose we focus the docs on the interaction of `UnsafeCell` and *shared references* specifically, which is really where they are needed.

…bank

Fix sizes of repr(C) enums on hexagon

Enums on hexagon use a smallest size (but at least 1 byte) that fits all
the enumeration values. This is unlike many other ABIs where enums are
at least 32 bits.

Fixes rust-lang#82100

…, r=jyn514

rustdoc: Remove `fake_def_ids` RefCell