Check cfg on features that stage0 compiler support

[a4lg]

Since the bootstrap compiler of Rust is bumped to the commit rust-lang/rust@5dadfd5 (version 1.88.0-beta.3 2025-05-11), some features should be safe to enable cfg checks.

This is a superset of the revert of #1768.

RISC-V Features:

• "zicsr"
• "zicntr"
• "zihpm"
• "zifencei"
• "zihintntl"
• "zihintpause"
• "zimop"
• "zicboz"
• "zicond"
• "ztso"
• "zfa"
• "zca"
• "zcb"
• "zcmop"
• "b"

x86 Features:

• "amx-avx512"
• "amx-fp8"
• "amx-movrs"
• "amx-tf32"
• "amx-transpose"

[rustbot]

r? @Amanieu

rustbot has assigned @Amanieu.
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

[a4lg]

@sayantn
Did something change in the Rust CI on the std rustdoc process? I'm wondering because I'm failing to reproduce a CI failure (to make sure that this PR is safe enough even if the Rust repository contains this).
While I'm investigating for this PR, I found that some vector extensions like zve32x should have been added with without cfg check: true (according to #1768) for being too new but added without it in #1770 and did not (itself) cause any errors in rust-lang/rust#140389.

A link to a CI failure (e.g. a comment by a bot) will be very helpful for me.

[sayantn]

That is quite interesting, I honestly have no idea why it did work as intended. Also, I think there were some changes to the rustc bootstrapping procedure lately, as I have noticed a little on the T-infra zulip streams 😅. You are sure that zve32x wasn't available with rustc 1.87 (the beta at the time it got merged in rustc) right? (Sorry can't check myself, don't have my laptop currently). Probably @Amanieu can shed some light on this

[a4lg]

@sayantn
Interestingly, yes. zve32x is added by the PR rust-lang/rust#138742 but it's clearly landed on 1.88. not 1.87.
I tried to break CI by removing without cfg check: true from RISC-V's zam (which is not supported by Rust's feature handling system) but it still succeeds (even dist-riscv64-linux).

After I mentioned you, I finally managed to break the CI by adding an unknown feature without without cfg check: true to x86.rs (fails on x86_64-gnu-llvm-19-2 but that was not an obvious rustdoc error).

[a4lg]

Rust's CI jobs x86_64-gnu-llvm-{19,20}-{1,2,3} (where most of the tests happen) succeeded on my local CI setup (Docker/Podman-based) emulating GitHub Actions with stdarch plus this PR.

Note: due to a possible bug, I had to run Docker images in the interactive mode ./src/ci/docker/run.sh --dev [IMAGE_NAME] and run each job as follows; otherwise specifying *-llvm-*-{2,3} tests using citool will run *-llvm-*-1 instead).

SCRIPT=/tmp/stage_2_test_set1.sh /checkout/src/ci/run.sh && \
SCRIPT=/tmp/x86_64-gnu-llvm2.sh  /checkout/src/ci/run.sh && \
SCRIPT=/tmp/x86_64-gnu-llvm3.sh  /checkout/src/ci/run.sh

[sayantn]

That is extremely weird, could you mention it in the T-compiler zulip so that someone more experienced can step in