Rollup merge of rust-lang#146520 - thejpster:promote-armv8r-none-eabi, r=petrochenkov

Promote armv8r-none-eabihf target to Tier 2

This PR promotes armv8r-none-eabihf to Tier 2, joining armv7r-none-eabi, armv7r-none-eabihf and armv7a-none-eabi.

This PR wil be rebased once rust-lang#146419 completes the queue.

> - A tier 2 target must have value to people other than its maintainers. (It may
>   still be a niche target, but it must not be exclusively useful for an
>   inherently closed group.)

The `armv8r-none-eabihf` target is for the Arm Cortex-R52 processor, as found in a number of Automotive SoCs that have just been released, or are about to be released. Currently SoCs are available from NXP and Renesas.

>- A tier 2 target must have a designated team of developers (the "target
>  maintainers") available to consult on target-specific build-breaking issues,
>  or if necessary to develop target-specific language or library implementation
>  details. This team must have at least 2 developers.

The Embedded Devices Working Group's Arm Team have just started maintaining this target.

> - The target must not place undue burden on Rust developers not specifically
>   concerned with that target. Rust developers are expected to not gratuitously
>   break a tier 2 target, but are not expected to become experts in every tier 2
>   target, and are not expected to provide target-specific implementations for
>   every tier 2 target.

This target is highly similar to a number of existing Tier 2 targets, including `armv7r-none-eabihf` and so it should not add undue burden.

> - The target must provide documentation for the Rust community explaining how
>   to build for the target using cross-compilation, and explaining how to run
>   tests for the target. If at all possible, this documentation should show how
>   to run Rust programs and tests for the target using emulation, to allow
>   anyone to do so. If the target cannot be feasibly emulated, the documentation
>   should explain how to obtain and work with physical hardware, cloud systems,
>   or equivalent.

https://doc.rust-lang.org/nightly/rustc/platform-support/armv8r-none-eabihf.html exists and was updated in rust-lang#146419

> - The target must document its baseline expectations for the features or
>   versions of CPUs, operating systems, libraries, runtime environments, and
>   similar.

I believe it does.

> - If introducing a new tier 2 or higher target that is identical to an existing
>   Rust target except for the baseline expectations for the features or versions
>   of CPUs, operating systems, libraries, runtime environments, and similar,
>   then the proposed target must document to the satisfaction of the approving
>   teams why the specific difference in baseline expectations provides
>   sufficient value to justify a separate target.

The Armv8-R architecture introduces a new FPU type, the fp-armv8, and so this requires a unique target.

> - Tier 2 targets must not leave any significant portions of `core` or the
>  standard library unimplemented or stubbed out, unless they cannot possibly be
>  supported on the target.

It has a full libcore, as per the other arm*-none-* targets.

> - The code generation backend for the target should not have deficiencies that
>  invalidate Rust safety properties, as evaluated by the Rust compiler team.

It should be the same backend as `armv7r-none-eabihf` and friends, except for FPU support, which is already covered in `thumbv8m.main-none-eabihf`. There are no issues that I know of.

> - If the target supports C code, and the target has an interoperable calling
>   convention for C code, the Rust target must support that C calling convention
>   for the platform via `extern "C"`. The C calling convention does not need to
>   be the default Rust calling convention for the target, however.

The ABI is EABI, the same as many other Arm targets.

> - The target must build reliably in CI, for all components that Rust's CI
>   considers mandatory.

The https://github.com/rust-embedded/cortex-ar repository regularly builds this target with `-Zbuild-std=core` and it seems fine.

> - The approving teams may additionally require that a subset of tests pass in
>  CI, such as enough to build a functional "hello world" program, `./x.py test
>  --no-run`, or equivalent "smoke tests". In particular, this requirement may
>  apply if the target builds host tools, or if the tests in question provide
>  substantial value via early detection of critical problems.

There are no no-std tests in the tree that I'm aware of.

> - Building the target in CI must not take substantially longer than the current
>   slowest target in CI, and should not substantially raise the maintenance
>   burden of the CI infrastructure. This requirement is subjective, to be
>   evaluated by the infrastructure team, and will take the community importance
>   of the target into account.

Building libcore is quite fast.

> - Tier 2 targets should, if at all possible, support cross-compiling. Tier 2
>   targets should not require using the target as the host for builds, even if
>   the target supports host tools.

It does.

> - In addition to the legal requirements for all targets (specified in the tier
>   3 requirements), because a tier 2 target typically involves the Rust project
>   building and supplying various compiled binaries, incorporating the target
>   and redistributing any resulting compiled binaries (e.g. built libraries,
>   host tools if any) must not impose any onerous license requirements on any
>   members of the Rust project, including infrastructure team members and those
>   operating CI systems. This is a subjective requirement, to be evaluated by
>   the approving teams.

Just libcore required (and liballoc). No known issues here.

> - Tier 2 targets must not impose burden on the authors of pull requests, or
>   other developers in the community, to ensure that tests pass for the target.

Noted

> - The target maintainers should regularly run the testsuite for the target

The https://github.com/rust-embedded/cortex-ar repository will be changed to use the rustup component when available.

> and should fix any test failures in a reasonably timely fashion.

Noted

Author: dianqk