This ensures we won't accidentally read *src or *dest even when count = 0.

Co-Authored-By: Jack O'Connor <oconnor663@gmail.com>

Make sure we look for save analysis in the right place. Fixes rust-lang#61703.

Signed-off-by: Marc-Antoine Perennou <Marc-Antoine@Perennou.com>

The condition I suggested in rust-lang#61632 was not correct and it errors out
while evaluating. This fixes the condition.

Example of a failure:
https://dev.azure.com/rust-lang/rust/_build/results?buildId=543

…nSapin

Stabilize Option::xor

FCP done in rust-lang#50512 (comment) .

Closes rust-lang#50512 .

…monSapin

Stabilize copy_within

Closes rust-lang#54236.

Hygienize macros in the standard library

Same as rust-lang#55597, but for all macros in the standard library.
Nested macro calls will now call what they are intended to call rather than whatever is in the closest scope at call site.
Technically this is a breaking change, so crater run would probably be useful.

---

One exception that is not hygienized is calls to `panic!(...)`.
Macros defined in libcore do not want to call `core::panic`.
What they really want to call is either `std::panic` or `core::panic` depending on `no_std` settings.
EDIT: After some thought, recursive calls to `panic` from `panic` itself probably do want to use `$crate` (UPDATE: done).

Calling `std::panic` from macros defined in std and "whatever `panic` is in scope" from macros defined in libcore is probably even worse than always calling "whatever `panic` is in scope", so I kept the existing code.

The only way to do the std/core switch correctly that I'm aware of is to define a built-in panic macro that would dispatch to `std::panic` or `core::panic` using compiler magic.
Then standard library macros could delegate to this built-in macro.
The macro could be named `panic` too, that would fix rust-lang#61567.
(This PR doesn't do that.)

---
cc rust-lang#56389
cc rust-lang#61567
Fixes rust-lang#61699
r? @alexcrichton

Include frame pointer for bare metal RISC-V targets

This changes the default setting to enable the use of the frame pointer register when targeting RISC-V. On that architecture there is a dedicated frame pointer register which LLVM would otherwise never use so there is no increase in register pressure. Further, since these are bare metal targets, getting backtraces without the frame pointer is considerably more difficult (you can't just ask the OS to load the ELF executable and parse DWARF symbols). It is true that this setting can also be changed with the `-C force-frame-pointers` flag but that won't impact the compilation of the standard library, meaning that backtraces from, say, a panic handler would be useless.

Fix x.py install

Make sure we look for save analysis in the right place. Fixes rust-lang#61703.

r? @Mark-Simulacrum
cc @petrhosek @cramertj

Add an alias for x86_64-sun-solaris target tuple

Closes rust-lang#40531

r? @varkor

…rk-Simulacrum

rustbuild: fix libtest_stamp

Looks like an obvious copy/paste typo

…=alexcrichton

ci: fix ci stats upload condition

The condition I suggested in rust-lang#61632 was not correct and it errors out while evaluating. This fixes the condition. [Example of a failure](https://dev.azure.com/rust-lang/rust/_build/results?buildId=543).

r? @alexcrichton

…r=Centril

Fix typos in error_codes

`observedin` should be `observed in`.