Add support for hexagon-unknown-qurt target

[androm3da]

No description provided.

[rustbot]

These commits modify compiler targets.
(See the Target Tier Policy.)

Some changes occurred in src/doc/rustc/src/platform-support

cc @Noratrieb

[rustbot]

r? @BoxyUwU

rustbot has assigned @BoxyUwU.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[tgross35]

Procedurally, adding a new T3 target requires a MCP (Major Change Proposal), which is an issue template at https://github.com/rust-lang/compiler-team/issues. See rust-lang/compiler-team#911 for a recent example.

[jieyouxu]

Procedurally, adding a new T3 target requires a MCP (Major Change Proposal), which is an issue template at rust-lang/compiler-team/issues. See rust-lang/compiler-team#911 for a recent example.

(I believe that was revised to only require a PR (with the target tier policy for T3 filled out), and assigned to one of the compiler co-leads. For certain targets (especially the more obscure ones) we may ask for an MCP for further discusssions. This target seems... rather obscure, so an MCP seems beneficial.)

r? compiler_leads

[bjorn3]

What is the license of this SDK? Maybe you could link to the page that links to the zip file and presumably also the license.

[androm3da]

It's a proprietary SDK, hopefully the change makes this clearer.

[androm3da]

Procedurally, adding a new T3 target requires a MCP (Major Change Proposal), which is an issue template at rust-lang/compiler-team/issues. See rust-lang/compiler-team#911 for a recent example.

(I believe that was revised to only require a PR (with the target tier policy for T3 filled out), and assigned to one of the compiler co-leads. For certain targets (especially the more obscure ones) we may ask for an MCP for further discusssions. This target seems... rather obscure, so an MCP seems beneficial.)

r? compiler_leads

Happy to fill out an MCP - that makes sense to me.

But in filling it out, I think I've hit a roadblock that makes me consider abandoning this PR.

Targets must use naming consistent with any existing targets; for instance, a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains), unless they have a very good reason to diverge.

Of course - this policy makes perfect sense. For this particular target, it's generally targeted using the hexagon-unknown-elf triple when using clang -- not hexagon-unknown-qurt. This is unfortunate because it also means that clang doesn't emit preprocessor defines like __QURT__ because there's no distinction. But in places like Rust's libc, I want to be able to guard things with #[cfg(target_os = "qurt")].

Sorry - perhaps this discussion might be better on the MCP issue rather than this PR. We already have an hexagon-unknown-none-elf target in rustc. Should I just use that one instead or does this constitute a "very good reason to diverge"? It's definitely the case that some folks use other non-QuRT, non-Linux OSs on Hexagon DSPs, but -- for now -- this is probably only internal to Qualcomm.

[rust-log-analyzer]

The job aarch64-gnu-llvm-20-1 failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)

---- [ui] tests/ui/check-cfg/cfg-crate-features.rs stdout ----
Saved the actual stderr to `/checkout/obj/build/aarch64-unknown-linux-gnu/test/ui/check-cfg/cfg-crate-features/cfg-crate-features.stderr`
diff of stderr:

24 LL | #![cfg(not(target(os = "does_not_exist")))]
25    |                   ^^^^^^^^^^^^^^^^^^^^^
26    |
-    = note: expected values for `target_os` are: `aix`, `amdhsa`, `android`, `cuda`, `cygwin`, `dragonfly`, `emscripten`, `espidf`, `freebsd`, `fuchsia`, `haiku`, `hermit`, `horizon`, `hurd`, `illumos`, `ios`, `l4re`, `linux`, `lynxos178`, `macos`, `managarm`, `motor`, `netbsd`, `none`, `nto`, `nuttx`, `openbsd`, `psp`, `psx`, `qurt`, `redox`, `rtems`, `solaris`, `solid_asp3`, `teeos`, and `trusty` and 12 more
+    = note: expected values for `target_os` are: `aix`, `amdhsa`, `android`, `cuda`, `cygwin`, `dragonfly`, `emscripten`, `espidf`, `freebsd`, `fuchsia`, `haiku`, `hermit`, `horizon`, `hurd`, `illumos`, `ios`, `l4re`, `linux`, `lynxos178`, `macos`, `managarm`, `motor`, `netbsd`, `none`, `nto`, `nuttx`, `openbsd`, `psp`, `psx`, `qurt`, `redox`, `rtems`, `solaris`, `solid_asp3`, and `teeos` and 13 more
28    = note: see <https://doc.rust-lang.org/nightly/rustc/check-cfg.html> for more information about checking conditional configuration
29    = note: `#[warn(unexpected_cfgs)]` on by default
30 


The actual stderr differed from the expected stderr
To update references, rerun the tests and pass the `--bless` flag
To only update this specific test, also pass `--test-args check-cfg/cfg-crate-features.rs`

error: 1 errors occurred comparing output.
status: exit status: 1
command: env -u RUSTC_LOG_COLOR RUSTC_ICE="0" RUST_BACKTRACE="short" "/checkout/obj/build/aarch64-unknown-linux-gnu/stage2/bin/rustc" "/checkout/tests/ui/check-cfg/cfg-crate-features.rs" "-Zthreads=1" "-Zsimulate-remapped-rust-src-base=/rustc/FAKE_PREFIX" "-Ztranslate-remapped-path-to-local-path=no" "-Z" "ignore-directory-in-diagnostics-source-blocks=/cargo" "-Z" "ignore-directory-in-diagnostics-source-blocks=/checkout/vendor" "--sysroot" "/checkout/obj/build/aarch64-unknown-linux-gnu/stage2" "--target=aarch64-unknown-linux-gnu" "--check-cfg" "cfg(test,FALSE)" "--error-format" "json" "--json" "future-incompat" "-Ccodegen-units=1" "-Zui-testing" "-Zdeduplicate-diagnostics=no" "-Zwrite-long-types-to-disk=no" "-Cstrip=debuginfo" "--emit" "metadata" "-C" "prefer-dynamic" "--out-dir" "/checkout/obj/build/aarch64-unknown-linux-gnu/test/ui/check-cfg/cfg-crate-features" "-A" "unused" "-A" "internal_features" "-A" "unused_parens" "-A" "unused_braces" "-Crpath" "-Cdebuginfo=0" "-Lnative=/checkout/obj/build/aarch64-unknown-linux-gnu/native/rust-test-helpers"
stdout: none
--- stderr -------------------------------
error[E0658]: `cfg(version)` is experimental and subject to change
##[error]  --> /checkout/tests/ui/check-cfg/cfg-crate-features.rs:4:8
   |
LL | #![cfg(version("1.0"))]
   |        ^^^^^^^^^^^^^^
   |
   = note: see issue #64796 <https://github.com/rust-lang/rust/issues/64796> for more information
   = help: add `#![feature(cfg_version)]` to the crate attributes to enable
   = note: this compiler was built on YYYY-MM-DD; consider upgrading it if it is out of date

error[E0658]: compact `cfg(target(..))` is experimental and subject to change
##[error]  --> /checkout/tests/ui/check-cfg/cfg-crate-features.rs:9:12
   |
LL | #![cfg(not(target(os = "does_not_exist")))]
   |            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: see issue #96901 <https://github.com/rust-lang/rust/issues/96901> for more information
   = help: add `#![feature(cfg_target_compact)]` to the crate attributes to enable
   = note: this compiler was built on YYYY-MM-DD; consider upgrading it if it is out of date

warning: unexpected `cfg` condition value: `does_not_exist`
##[warning]  --> /checkout/tests/ui/check-cfg/cfg-crate-features.rs:9:19
   |
LL | #![cfg(not(target(os = "does_not_exist")))]
   |                   ^^^^^^^^^^^^^^^^^^^^^
   |
   = note: expected values for `target_os` are: `aix`, `amdhsa`, `android`, `cuda`, `cygwin`, `dragonfly`, `emscripten`, `espidf`, `freebsd`, `fuchsia`, `haiku`, `hermit`, `horizon`, `hurd`, `illumos`, `ios`, `l4re`, `linux`, `lynxos178`, `macos`, `managarm`, `motor`, `netbsd`, `none`, `nto`, `nuttx`, `openbsd`, `psp`, `psx`, `qurt`, `redox`, `rtems`, `solaris`, `solid_asp3`, and `teeos` and 13 more
   = note: see <https://doc.rust-lang.org/nightly/rustc/check-cfg.html> for more information about checking conditional configuration
   = note: `#[warn(unexpected_cfgs)]` on by default

error: aborting due to 2 previous errors; 1 warning emitted

[tgross35]

Targets must use naming consistent with any existing targets; for instance, a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains), unless they have a very good reason to diverge.

Of course - this policy makes perfect sense. For this particular target, it's generally targeted using the hexagon-unknown-elf triple when using clang -- not hexagon-unknown-qurt. This is unfortunate because it also means that clang doesn't emit preprocessor defines like __QURT__ because there's no distinction. But in places like Rust's libc, I want to be able to guard things with #[cfg(target_os = "qurt")].

Why doesn't Clang have a -qurt target, or why isn't it used? If there is a need to configure on qurt vs. not qurt (e.g. different system interfaces) then that's probably enough to justify a new Rust target. It just seems weird that Clang doesn't have the target if it's useful.

[androm3da]

Targets must use naming consistent with any existing targets; for instance, a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains), unless they have a very good reason to diverge.

Of course - this policy makes perfect sense. For this particular target, it's generally targeted using the hexagon-unknown-elf triple when using clang -- not hexagon-unknown-qurt. This is unfortunate because it also means that clang doesn't emit preprocessor defines like __QURT__ because there's no distinction. But in places like Rust's libc, I want to be able to guard things with #[cfg(target_os = "qurt")].

Why doesn't Clang have a -qurt target, or why isn't it used? If there is a need to configure on qurt vs. not qurt (e.g. different system interfaces) then that's probably enough to justify a new Rust target.

The Hexagon SDK toolchain ships with hexagon-clang -- this canonicalizes as hexagon-unknown-elf. By default hexagon-clang builds with a common C library and links in a crt0 for a baremetal OS. But for targeting QuRT, that behavior is explicitly overridden when invoking hexagon-clang to compile or link to additionally use QuRT include paths and link against QuRT libraries/crt0 instead. I don't know for sure but I suppose it's "simpler" this way -- or maybe it's just a historical thing that stays that way due to momentum.

If there is a need to configure on qurt vs. not qurt (e.g. different system interfaces) then that's probably enough to justify a new Rust target.

The Hexagon Linux target is not supported by the Hexagon SDK and so far that's really the only toolchain that's used to target QuRT. In practice, no commercial users of Hexagon target anything other than QuRT on Hexagon architecture. So IMO it's an oversimplification that happens to work. The opensource clang+llvm toolchain (see build recipe ) could conceivably target QuRT but is missing a C library that would work with QuRT, so in practice no one uses it for that -- yet.

It just seems weird that Clang doesn't have the target if it's useful.

My understanding is that clang could take a hexagon-unknown-qurt triple and it would probably work reasonably well if it were interpreted as having the same behavior as hexagon-unknown-none-elf / hexagon-unknown-elf. I don't recall for sure but I suppose the clang driver might do just that. And if not, it's not hard to change it to do so. But -- it's untested and definitely not how it's been done by the Hexagon SDK over the years. I hope I am just being overly cautious here but Rust's policy regarding target names makes a lot of sense to me.