Rollup merge of #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 #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 #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

compiler/rustc_target/src/spec/targets/armv8r_none_eabihf.rs

@@ -10,7 +10,7 @@ pub(crate) fn target() -> Target {
         llvm_target: "armv8r-none-eabihf".into(),
         metadata: TargetMetadata {
             description: Some("Bare Armv8-R, hardfloat".into()),
-            tier: Some(3),
+            tier: Some(2),
             host_tools: Some(false),
             std: Some(false),
         },

src/doc/rustc/src/platform-support.md

@@ -165,6 +165,7 @@ target | std | notes
 [`armv7a-none-eabi`](platform-support/armv7a-none-eabi.md) | * | Bare Armv7-A
 [`armv7r-none-eabi`](platform-support/armv7r-none-eabi.md) | * | Bare Armv7-R
 [`armv7r-none-eabihf`](platform-support/armv7r-none-eabi.md) | * | Bare Armv7-R, hardfloat
+[`armv8r-none-eabihf`](platform-support/armv8r-none-eabihf.md) | * |  | Bare Armv8-R, hardfloat
 `i586-unknown-linux-gnu` | ✓ | 32-bit Linux (kernel 3.2+, glibc 2.17, original Pentium) [^x86_32-floats-x87]
 `i586-unknown-linux-musl` | ✓ | 32-bit Linux (musl 1.2.3, original Pentium) [^x86_32-floats-x87]
 [`i686-linux-android`](platform-support/android.md) | ✓ | 32-bit x86 Android ([Pentium 4 plus various extensions](https://developer.android.com/ndk/guides/abis.html#x86)) [^x86_32-floats-return-ABI]
@@ -305,7 +306,6 @@ target | std | host | notes
 [`armv7a-vex-v5`](platform-support/armv7a-vex-v5.md) | ? |  | Armv7-A Cortex-A9 VEX V5 Brain, VEXos
 [`armv7k-apple-watchos`](platform-support/apple-watchos.md) | ✓ |  | Armv7-A Apple WatchOS
 [`armv7s-apple-ios`](platform-support/apple-ios.md) | ✓ |  | Armv7-A Apple-A6 Apple iOS
-[`armv8r-none-eabihf`](platform-support/armv8r-none-eabihf.md) | * |  | Bare Armv8-R, hardfloat
 [`armv7a-nuttx-eabi`](platform-support/nuttx.md) | ✓ |  | ARMv7-A with NuttX
 [`armv7a-nuttx-eabihf`](platform-support/nuttx.md) | ✓ |  | ARMv7-A with NuttX, hardfloat
 [`avr-none`](platform-support/avr-none.md) | * |  | AVR; requires `-Zbuild-std=core` and `-Ctarget-cpu=...`

src/doc/rustc/src/platform-support/armv8r-none-eabihf.md

@@ -1,6 +1,6 @@
 # `armv8r-none-eabihf`
 
-* **Tier: 3**
+* **Tier: 2**
 * **Library Support:** core and alloc (bare-metal, `#![no_std]`)
 
 Bare-metal target for CPUs in the Armv8-R architecture family, supporting