arm64e: align Apple ptrauth lowering and visionOS bootstrap

[cypherair]

Summary

• add a dedicated SSA path for function addresses used as data on Apple arm64e
• lower data-side function pointers through LLVMConstantPtrAuth
• extend constant/vtable function relocations to use the same authenticated representation
• add the missing arm64e ptrauth operand bundle on invoke, which fixes the __rust_try / TLS path
• allow bootstrap to accept the downstream arm64e-apple-visionos target while the current stage0 compiler still does not list it
• add codegen regressions for function-pointer-as-data and __rust_try indirect invoke lowering

Latest update

• fix the LLVMConstantPtrAuth address-discriminator operand used for arm64e function pointers as data
• pass ptr null instead of i64 0, which is required by the LLVM verifier on both LLVM 21 and LLVM 22
• add -Zverify-llvm-ir coverage to the arm64e fnptr-data and invoke codegen tests so this class of bug is caught locally instead of only in external LLVM CI
• clean up the tidy issues touched by this follow-up so the draft PR stays green once the verifier fix lands

Root cause

GitHub's aarch64-gnu-llvm-21-1 job was failing on the new arm64e function-pointer-as-data tests with:

signed ptrauth constant address discriminator must be a pointer

The bug was in the Rust-side LLVMConstantPtrAuth construction for data-side function pointers: we were passing the address discriminator as an integer zero instead of a pointer-typed null value. The printed LLVM IR looked reasonable enough that the default local codegen-llvm path did not catch it, but explicit -Zverify-llvm-ir reproduces the same verifier failure locally. This follow-up fixes the operand shape and makes the tests verify the LLVM IR explicitly.

Notes

• Clang arm64e IR still uses a different constant-storage shape for function pointers used as data, so this PR is intentionally scoped to the minimal verifier-safe fix first
• if runtime behavior or assembly still diverges after this lands, the next step is a separate follow-up to evaluate converging on Clang's llvm.ptrauth storage model more closely
• arm64e-apple-visionos remains a downstream-only experiment target on this branch

Validation

• python x.py check compiler/rustc_codegen_ssa compiler/rustc_codegen_llvm --stage 1
• python x.py test --stage 1 tests/codegen-llvm/arm64e-apple-ptrauth-fnptr-data.rs tests/codegen-llvm/arm64e-apple-ptrauth-invoke.rs
• explicit stage1 verifier checks:
  • build/aarch64-apple-darwin/stage1/bin/rustc tests/codegen-llvm/arm64e-apple-ptrauth-fnptr-data.rs --target arm64e-apple-darwin -Copt-level=0 --emit llvm-ir -Zverify-llvm-ir ...
  • build/aarch64-apple-darwin/stage1/bin/rustc tests/codegen-llvm/arm64e-apple-ptrauth-invoke.rs --target arm64e-apple-darwin -Copt-level=0 -Cpanic=unwind --emit llvm-ir -Zverify-llvm-ir ...
• python x.py test src/tools/tidy tidyselftest --stage 1
• earlier branch validation from the draft still applies for the broader arm64e lowering/runtime work

[cypherair]

Superseded for current upstream-prep work by #3.\n\nWe are intentionally keeping and this draft PR as the historical spike snapshot, while the rebased prep work now continues on .

[cypherair]

Superseded for current upstream-prep work by #3.

We are intentionally keeping codex/arm64e-darwin-ptrauth-spike and this draft PR as the historical spike snapshot, while the rebased prep work now continues on codex/arm64e-upstream-prep-base-2026-04-23-u827651f.