Skip to content

stdarch-gen-hexagon-scalar: Do not emit inline(always) if target_feature is used#2133

Open
taiki-e wants to merge 2 commits into
rust-lang:mainfrom
taiki-e:hexagon-scalar
Open

stdarch-gen-hexagon-scalar: Do not emit inline(always) if target_feature is used#2133
taiki-e wants to merge 2 commits into
rust-lang:mainfrom
taiki-e:hexagon-scalar

Conversation

@taiki-e
Copy link
Copy Markdown
Member

@taiki-e taiki-e commented May 23, 2026

stdarch-gen-hexagon-scalar, which added in #2072, always emits #[inline(always)], but it cause compile errors on functions that have #[target_feature].

  error: cannot use `#[inline(always)]` with `#[target_feature]`
       --> /home/runner/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/../../stdarch/crates/core_arch/src/hexagon/scalar.rs:11428:1
        |
  11428 | #[inline(always)]
        | ^^^^^^^^^^^^^^^^^
        |
        = note: See this issue for full discussion: https://github.com/rust-lang/rust/issues/145574

hexagon-unknown-linux-musl build is broken due to this issue since nightly-2026-05-22: https://github.com/taiki-e/atomic-maybe-uninit/actions/runs/26266025199/job/77310173101#step:4:929

This PR fixes it by emitting #[inline] instead of #[inline(always)] if #[target_feature] is used.
(Confirmed with cargo +nightly-2026-05-21 build -Z build-std=core -p core_arch --target hexagon-unknown-linux-musl)

This also add missing stdarch-gen output check for stdarch-gen-hexagon-scalar.

cc @androm3da
cc rust-lang/rust#151523
Fixes #2134

@rustbot
Copy link
Copy Markdown
Collaborator

rustbot commented May 23, 2026

r? @adamgemmell

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

Why was this reviewer chosen?

The reviewer was selected based on:

  • Owners of files modified in this PR: @Amanieu, @adamgemmell, @davidtwco, @folkertdev, @sayantn
  • @Amanieu, @adamgemmell, @davidtwco, @folkertdev, @sayantn expanded to Amanieu, adamgemmell, davidtwco, folkertdev, sayantn
  • Random selection from Amanieu, adamgemmell, davidtwco, folkertdev, sayantn

@taiki-e
Copy link
Copy Markdown
Member Author

taiki-e commented May 23, 2026

CI failure seems to be unrelated

https://github.com/rust-lang/stdarch/actions/runs/26325152273/job/77501386688?pr=2133

+ cargo fmt --all -- --check
Diff in /home/runner/work/stdarch/stdarch/crates/core_arch/src/loongarch64/simd.rs:17:
 macro_rules! impl_simd_ext {
     ($v:ident, $e:ty) => {
         #[rustc_const_unstable(feature = "stdarch_const_helpers", issue = "none")]
-        impl const SimdExt for crate::core_arch::simd::$v {
+        const impl SimdExt for crate::core_arch::simd::$v {
             type Elem = $e;
 
             #[inline(always)]
Diff in /home/runner/work/stdarch/stdarch/crates/core_arch/src/simd.rs:87:
 }
 
 #[rustc_const_unstable(feature = "stdarch_const_helpers", issue = "none")]
-impl<T: SimdElement, const N: usize> const crate::cmp::PartialEq for Simd<T, N> {
+const impl<T: SimdElement, const N: usize> crate::cmp::PartialEq for Simd<T, N> {
     #[inline]
     fn eq(&self, other: &Self) -> bool {
         self.as_array() == other.as_array()
Diff in /home/runner/work/stdarch/stdarch/crates/core_arch/src/simd.rs:299:
 }
 
 #[rustc_const_unstable(feature = "stdarch_const_helpers", issue = "none")]
-impl<T: SimdElement, const N: usize> const crate::cmp::PartialEq for SimdM<T, N> {
+const impl<T: SimdElement, const N: usize> crate::cmp::PartialEq for SimdM<T, N> {
     #[inline]
     fn eq(&self, other: &Self) -> bool {
         self.as_array() == other.as_array()

I don't know anything about the current status of const impl, but the code in rust-lang/rust is the same, and it seems that both const impl and impl const are valid in the first place? So why is rustfmt making changes here?

@taiki-e
Copy link
Copy Markdown
Member Author

taiki-e commented May 23, 2026

CI failure seems to be unrelated

I don't know anything about the current status of const impl, but the code in rust-lang/rust is the same, and it seems that both const impl and impl const are valid in the first place? So why is rustfmt making changes here?

Added #[rustfmt::skip] for now: 44102ca

taiki-e added a commit to taiki-e/atomic-maybe-uninit that referenced this pull request May 23, 2026
taiki-e added a commit to taiki-e/atomic-maybe-uninit that referenced this pull request May 23, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Breaking changes error in Rust nightly 1.98 for target hexagon-unknown-linux-musl

4 participants