Allow for reading raw bytes from rustc_serialize::Decoder without unsafe code

[michaelwoerister]

The current read_raw_bytes method requires using MaybeUninit and unsafe. I don't think this is necessary. Let's see if a safe interface has any performance drawbacks.

This is a followup to #83273 and will make it easier to rebase #82183.

r? @cjgillot

[michaelwoerister]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

[bors]

⌛ Trying commit 517d5ac with merge 8454a31114a0ff65016cc30a4c74570cdabc03b2...

[bors]

☀️ Try build successful - checks-actions
Build commit: 8454a31114a0ff65016cc30a4c74570cdabc03b2 (8454a31114a0ff65016cc30a4c74570cdabc03b2)

[rust-timer]

Queued 8454a31114a0ff65016cc30a4c74570cdabc03b2 with parent 372afcf, future comparison URL.

[rust-timer]

Finished benchmarking try commit (8454a31114a0ff65016cc30a4c74570cdabc03b2): comparison url.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying rollup- to bors.

Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up.

@bors rollup=never
@rustbot label: +S-waiting-on-review -S-waiting-on-perf

[cjgillot]

@bors r+

[bors]

📌 Commit 517d5ac has been approved by cjgillot

[michaelwoerister]

There seems to be a slight regression in terms of instruction counts. Interestingly, using &mut [u8] instead of &mut [MaybeUninit<u8>] does not seem to be the cause of that. Instead it is the copy_from_slice() call instead ot the copy_non_overlapping() that introduces an additional check (making sure that the start index is less than or equal to the end index).

I've tested a few different versions at https://play.rust-lang.org/?version=nightly&mode=release&edition=2018&gist=4933fb0cfc1884086c846c98260bd4c7. The assembly code of all versions that avoid that additional check look the same (or almost the same) and should perform the same. I'm not sure yet if we really should skip that additional check. In theory the self.position += s.len() addition could overflow, causing undefined behavior.

[cjgillot]

The regression in instruction count is within noise, with no actual effect on wall-time. max-rss is green-ish.
I am not really concerned by this additional check, as it could fire in the unlikely case of overflow.

[bors]

⌛ Testing commit 517d5ac with merge 0ced530...

[bors]

☀️ Test successful - checks-actions
Approved by: cjgillot
Pushing 0ced530 to master...