…ata loss

…se and number. This example makes it clear for programmers who take a glance at the example by following the calculation. It is more intuitive, and eliminates the need for executing the example in the playground.

…_mut`

Co-Authored-By: Mazdak Farrokhzad <[email protected]>

And change `rmeta.rs` to `rmeta/mod.rs`

…=KodrAus

Enhance the documentation of BufReader for potential data loss

This is (IMO) and enhancement of the `std::io::BufReader` documentation, that aims to highlight how relatively easy is to end up with data loss when improperly using an instance of this class.

This is following the issue I had figuring out why my application was loosing data, because I focused my attention on the word *multiple instances* of `BufReader` in its `struct` documentation, even if I ever only had one instance.

Link to the issue: tokio-rs/tokio#1662

…nieu

Add `MaybeUninit` methods `uninit_array`, `slice_get_ref`, `slice_get_mut`

Eventually these will hopefully become the idiomatic way to work with partially-initialized stack buffers.

All methods are unstable. Note that `uninit_array` takes a type-level `const usize` parameter, so it is blocked (at least in its current form) on const generics.

Example:

```rust
use std::mem::MaybeUninit;

let input = b"Foo";
let f = u8::to_ascii_uppercase;

let mut buffer: [MaybeUninit<u8>; 32] = MaybeUninit::uninit_array();
let vec;
let output = if let Some(buffer) = buffer.get_mut(..input.len()) {
    buffer.iter_mut().zip(input).for_each(|(a, b)| { a.write(f(b)); });
    unsafe { MaybeUninit::slice_get_ref(buffer) }
} else {
    vec = input.iter().map(f).collect::<Vec<u8>>();
    &vec
};

assert_eq!(output, b"FOO");
```

consistent handling of missing sysroot spans

Due to rust-lang#53081, sysroot spans (pointing to code in libcore/libstd/...) fails to print on some x86 runners. This consolidates the ignore directives for that and references the relevant issue.

I also did that for the generated derive-error-span tests -- but there the script and the tests were not entirely in sync any more since rust-lang#64151. Cc @estebank @varkor

rustc_metadata: Some reorganization of the module structure

The new structure of `rustc_metadata` (or rather its parts affected by the refactoring) is
```
├── lib.rs
└── rmeta
    ├── decoder
    │   └── cstore_impl.rs
    ├── decoder.rs
    ├── encoder.rs
    ├── mod.rs
    └── table.rs
```

(`schema` is renamed to `rmeta`.)

The code inside `rmeta` is pretty self-contained, so we can now privatize almost everything in this module instead of using `pub(crate)`  which was necessary when all these modules accessed their neighbors in the old flat structure.

`encoder` and `decoder` work with structures defined by `rmeta`.
`table` is a part of `rmeta`.
`cstore_impl` actively uses decoder methods and exposes their results through very few public methods (`provide` and `_untracked` methods).

r? @eddyb @spastorino

…nts, r=Dylan-DPC

No more hidden elements

Fixes rust-lang#66046.

Follow-up of rust-lang#66082.

r? @kinnison

Improve math log documentation examples

using 2.0.log(2.0) in examples does not make it clear which is the base and number. This example makes it clear for programmers who take a glance at the example by following the calculation. It is more intuitive, and eliminates the need for executing the example in the playground.

Ignore these tests ,since the called commands doesn't exist in VxWorks

rustc_target: inline abi::FloatTy into abi::Primitive.

This effectively undoes a small part of @oli-obk's rust-lang#50967, now that the rest of the compiler doesn't use the `FloatTy` definition from `rustc_target`, post-rust-lang#65884.