arm `rustdoc` Rust 1.85.0-only build error

arm `rustdoc` Rust 1.85.0-only build error

[Miguel Ojeda]

Hi Christian, Russell, arm, Fabian,

For Rust 1.85.0, for arm32, for the `rustdoc` target (i.e. all those
combined), I am seeing:

      RUSTDOC   .../1.85.0-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/lib.rs
    error: target feature `fp-armv8` cannot be toggled with `#[target_feature]`: Rust ties `fp-armv8` to `neon`
        --> .../1.85.0-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/../../stdarch/crates/core_arch/src/arm_shared/neon/generated.rs:7538:48
         |
    7538 | #[cfg_attr(target_arch = "arm", target_feature(enable = "fp-armv8,v8"))]
         |                                                ^^^^^^^^^^^^^^^^^^^^^

The issue is [1], was introduced in Rust 1.85.0 and was fixed already in
Rust 1.85.1 [2]:

  Link: https://github.com/rust-lang/rust/issues/137366 [1]
  Link: https://github.com/rust-lang/rust/pull/137632 [2]

It is unfortunate since our minimum is going to be 1.85.0 since that is
what Debian Stable has (even if patches may be on top) -- I generally
test the latest patch versions for each minor, but I noticed this since
I also test the actual minimum, and I am bumping it to 1.85.0.

To be clear, it is likely almost no one actually cares about this, since
nobody complained yet, and this can easily be fixed using the already
released Rust 1.85.1.

By the way, what is Debian's policy on upstream Rust patch versions?

Thanks!

Cheers,
Miguel

Re: arm `rustdoc` Rust 1.85.0-only build error

[Fabian Grünbichler]

On Tue, Mar 31, 2026, at 9:00 PM, Miguel Ojeda wrote:
> Hi Christian, Russell, arm, Fabian,
>
> For Rust 1.85.0, for arm32, for the `rustdoc` target (i.e. all those
> combined), I am seeing:
>
>       RUSTDOC   
> .../1.85.0-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/lib.rs
>     error: target feature `fp-armv8` cannot be toggled with 
> `#[target_feature]`: Rust ties `fp-armv8` to `neon`
>         --> 
> .../1.85.0-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/../../stdarch/crates/core_arch/src/arm_shared/neon/generated.rs:7538:48
>          |
>     7538 | #[cfg_attr(target_arch = "arm", target_feature(enable = 
> "fp-armv8,v8"))]
>          |                                                
> ^^^^^^^^^^^^^^^^^^^^^
>
> The issue is [1], was introduced in Rust 1.85.0 and was fixed already in
> Rust 1.85.1 [2]:
>
>   Link: https://github.com/rust-lang/rust/issues/137366 [1]
>   Link: https://github.com/rust-lang/rust/pull/137632 [2]
>
> It is unfortunate since our minimum is going to be 1.85.0 since that is
> what Debian Stable has (even if patches may be on top) -- I generally
> test the latest patch versions for each minor, but I noticed this since
> I also test the actual minimum, and I am bumping it to 1.85.0.
>
> To be clear, it is likely almost no one actually cares about this, since
> nobody complained yet, and this can easily be fixed using the already
> released Rust 1.85.1.
>
> By the way, what is Debian's policy on upstream Rust patch versions?

In unstable, we pull them in usually by virtue of lagging behind a bit anyway.

In stable there is no policy per se - both importing a new smallish important
upstream release, or cherry-picking patches are options in general. A few
packages with clear upstream LTS policies are updated often (systemd, glibc,
the kernel itself, firefox-esr and chromium would be the most popular
examples). If there is no upstream stable release series that matches Debian
stable policies, the usual approach is to do a targeted backport of just the
fixes.

It's a bit unfortunate that the timing lined up like it did, because given the
lack of rustc LTS, usually there are no point releases for the version to be
included in Debian stable anyway.

It's up to the stable release managers how big of a delta is acceptable.

I will check how the full diff for 1.85.1 looks like compared to just picking
the rustdoc fix referenced above, and then file a stable update request. AFAIU
either option works for you?

The next Trixie point release is slated for May 16th, so we still have a bit of
time to discuss this with SRM.

Fabian

Re: arm `rustdoc` Rust 1.85.0-only build error

[Miguel Ojeda]

On Fri, Apr 3, 2026 at 10:12 AM Fabian Grünbichler
<debian@fabian.gruenbichler.email> wrote:
>
> I will check how the full diff for 1.85.1 looks like compared to just picking
> the rustdoc fix referenced above, and then file a stable update request. AFAIU
> either option works for you?

Thanks for the reply and the details! Yeah, the timing was unfortunate :)

Either works for us, in the sense that it is not a critical issue
(i.e. it is just for generating the docs and just for arm32).

Having said that, having the actual .1 release there is nicer in that
we could consider raising the minimum version to that one (or perhaps
at least print a warning if using .0).

It also means we may get more focused testing and one less version
around (e.g. currently I found this because I test our minimum, but
generally I test the latest point versions).

Cheers,
Miguel

Re: arm `rustdoc` Rust 1.85.0-only build error

[Gary Guo]

On Fri Apr 3, 2026 at 9:12 AM BST, Fabian Grünbichler wrote:
> On Tue, Mar 31, 2026, at 9:00 PM, Miguel Ojeda wrote:
>> Hi Christian, Russell, arm, Fabian,
>>
>> For Rust 1.85.0, for arm32, for the `rustdoc` target (i.e. all those
>> combined), I am seeing:
>>
>>       RUSTDOC   
>> .../1.85.0-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/lib.rs
>>     error: target feature `fp-armv8` cannot be toggled with 
>> `#[target_feature]`: Rust ties `fp-armv8` to `neon`
>>         --> 
>> .../1.85.0-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/../../stdarch/crates/core_arch/src/arm_shared/neon/generated.rs:7538:48
>>          |
>>     7538 | #[cfg_attr(target_arch = "arm", target_feature(enable = 
>> "fp-armv8,v8"))]
>>          |                                                
>> ^^^^^^^^^^^^^^^^^^^^^
>>
>> The issue is [1], was introduced in Rust 1.85.0 and was fixed already in
>> Rust 1.85.1 [2]:
>>
>>   Link: https://github.com/rust-lang/rust/issues/137366 [1]
>>   Link: https://github.com/rust-lang/rust/pull/137632 [2]
>>
>> It is unfortunate since our minimum is going to be 1.85.0 since that is
>> what Debian Stable has (even if patches may be on top) -- I generally
>> test the latest patch versions for each minor, but I noticed this since
>> I also test the actual minimum, and I am bumping it to 1.85.0.
>>
>> To be clear, it is likely almost no one actually cares about this, since
>> nobody complained yet, and this can easily be fixed using the already
>> released Rust 1.85.1.
>>
>> By the way, what is Debian's policy on upstream Rust patch versions?
>
> In unstable, we pull them in usually by virtue of lagging behind a bit anyway.
>
> In stable there is no policy per se - both importing a new smallish important
> upstream release, or cherry-picking patches are options in general. A few
> packages with clear upstream LTS policies are updated often (systemd, glibc,
> the kernel itself, firefox-esr and chromium would be the most popular
> examples). If there is no upstream stable release series that matches Debian
> stable policies, the usual approach is to do a targeted backport of just the
> fixes.
> lack of rustc LTS, usually there are no point releases for the version to be
> included in Debian stable anyway.
>
> It's up to the stable release managers how big of a delta is acceptable.
>
> I will check how the full diff for 1.85.1 looks like compared to just picking
> the rustdoc fix referenced above, and then file a stable update request. AFAIU
> either option works for you?

You can check diff here:
https://github.com/rust-lang/rust/compare/1.85.0...1.85.1

The change is not much, there is a library change although that's for Windows
only. The compiler and rustdoc changes are usually pretty harmless to backport.

I guess for Debian you cared about binary compatibility; in which case you
probably want to keep the compiler version number at 1.85.0, so the compiler
verison hash stays unchanged.

Best,
Gary