Open Bug 2038504 Opened 10 days ago Updated 4 days ago

fix building esr140 with llvm22

Categories

(Firefox Build System :: General, defect)

Product:
Firefox Build System
Component:
General
Version:
Firefox 140
Type:
defect

Tracking

(Not tracked)

People

(Reporter: gaston, Assigned: gaston)

References

Details

Attachments

(1 file)

jumbo patch backporting D262840 to esr140 branch
592.42 KB, patch
Details | Diff | Splinter Review

in the process of moving our (OpenBSD) default toolchain to llvm22, i've first worked on the wasi stack, and managed to build a working 151.0b8 with llvm 22 and rust 1.95 (built with llvm 20).

using the same toolchains and trying to build 140.10.2, it fails in mysterious ways in rust code at many places:

error[E0432]: unresolved import `nss_prelude::SECItemType`
  --> /usr/obj/ports/firefox-esr-140.10.2/firefox-140.10.2/third_party/rust/nss-gk-api/src/lib.rs:52:46
   |
52 | pub use nss_prelude::{SECItem, SECItemArray, SECItemType, SECStatus};
   |                                              ^^^^^^^^^^^ no `SECItemType` in `nss_prelude`
...
error[E0609]: no field `type_` on type `&SECItemStr`
  --> /usr/obj/ports/firefox-esr-140.10.2/firefox-140.10.2/third_party/rust/nss-gk-api/src/util.rs:90:25
   |
90 |         assert_eq!(self.type_, SECItemType::siBuffer);
   |                         ^^^^^ unknown field
   |
   = note: available field is: `_address`

error[E0433]: cannot find type `SECItemType` in this scope
  --> /usr/obj/ports/firefox-esr-140.10.2/firefox-140.10.2/third_party/rust/nss-gk-api/src/util.rs:90:32
   |
90 |         assert_eq!(self.type_, SECItemType::siBuffer);
   |                                ^^^^^^^^^^^ use of undeclared type `SECItemType`

...
error[E0609]: no field `mServoData` on type `&'le gecko_bindings::structs::root::mozilla::dom::Element`
    --> servo/components/style/gecko/wrapper.rs:1488:20
     |
1488 |             self.0.mServoData.set(ptr::null_mut());
     |                    ^^^^^^^^^^ unknown field
     |
     = note: available field is: `_address`

error[E0609]: no field `writing_mode` on type `&generated::gecko::ComputedValues`
    --> servo/components/style/gecko/wrapper.rs:1594:49
     |
1594 |                 .to_physical(after_change_style.writing_mode);
     |                                                 ^^^^^^^^^^^^ unknown field
     |
     = note: available field is: `_address`
...
error[E0599]: no method named `mIsStatic` found for struct `gecko_bindings::structs::root::nsAtom` in the current scope
   --> servo/components/style/gecko_string_cache/mod.rs:253:16
    |
253 |         self.0.mIsStatic() != 0
    |                ^^^^^^^^^ method not found in `gecko_bindings::structs::root::nsAtom`
    |
   ::: /usr/obj/ports/firefox-esr-140.10.2/build-amd64/x86_64-unknown-openbsd/release/build/style-505759164bc5d973/out/gecko/structs.rs:20:1522294
    |
 20 | ...t's not our problem"] # [repr (C)] # [derive (Debug , Copy , Clone)] pub struct nsAtom { pub _address : u8 , } # [test] fn bindgen_test_layout_nsAtom () { assert_eq ! (:: std :: mem :: size_of :: < nsA...
    |                                                                         ----------------- method `mIsStatic` not found for this struct

there are many different errors as the compiler summarizes them:

Some errors have detailed explanations: E0080, E0119, E0184, E0308, E0425, E0432, E0433, E0531, E0560...

building with llvm19 doesn't yield those strange issues. i've tried looking at the compile options passed to rustc/cargo invocations and found no differences with a working build.

i've looked in bugzilla and only found https://bugzilla.mozilla.org/show_bug.cgi?id=1979820 which doesnt seem related.

Summary: building esr140 with llvm22 fails in rust code with missing structs/symbols → building esr140 with llvm22 fails in rust code with missing structs/symbols/field/defines/types

list of error types from my build log:

$grep ^error\\[ build-140.10.2esr-1778429193-llvm22-nopgo |cut -d: -f1 |sort -u
error[E0080]
error[E0119]
error[E0184]
error[E0308]
error[E0422]
error[E0425]
error[E0432]
error[E0433]
error[E0531]
error[E0560]
error[E0599]
error[E0609]
error[E0615]

and since i know nothing to the rust codebase, after looking it seems all the missing symbols/fields/etc are defined in files that would be generated during build by rust-bindgen (thanks semarie for the pointer) ? building esr140 with llvm 20 is just fine. will check 21 too, and start looking at the differences between the various generated files depending on the llvm version used.

just taking nss_prelude.rs as an example, when generated with llvm20 and llvm22, after passing the files through rustfmt for diffability:

--- l20.rs      Sun May 10 21:08:06 2026
+++ l22.rs      Sun May 10 21:08:10 2026
@@ -1,36 +1,13 @@                                                                                         
 /* automatically generated by rust-bindgen 0.69.4 */
                              
-pub mod SECItemType {           
-    pub type Type = ::std::os::raw::c_uint;
-    pub const siBuffer: Type = 0;
-    pub const siClearDataBuffer: Type = 1;                                                               
-    pub const siCipherDataBuffer: Type = 2;
-    pub const siDERCertBuffer: Type = 3;
-    pub const siEncodedCertBuffer: Type = 4;
-    pub const siDERNameBuffer: Type = 5;                                                                 
-    pub const siEncodedNameBuffer: Type = 6;
-    pub const siAsciiNameString: Type = 7;
-    pub const siAsciiString: Type = 8;
-    pub const siDEROID: Type = 9;       
-    pub const siUnsignedInteger: Type = 10;
-    pub const siUTCTime: Type = 11;                                                                      
-    pub const siGeneralizedTime: Type = 12;
-    pub const siVisibleString: Type = 13;
-    pub const siUTF8String: Type = 14;
-    pub const siBMPString: Type = 15;
-}                                         
 pub type SECItem = SECItemStr;
 #[repr(C)]
 #[derive(Debug, Copy, Clone)]
 pub struct SECItemStr {
-    pub type_: SECItemType::Type,
-    pub data: *mut ::std::os::raw::c_uchar,
-    pub len: ::std::os::raw::c_uint,
+    pub _address: u8,
 }
 #[test]
 fn bindgen_test_layout_SECItemStr() {
-    const UNINIT: ::std::mem::MaybeUninit<SECItemStr> = ::std::mem::MaybeUninit::uninit();
-    let ptr = UNINIT.as_ptr();
     assert_eq!(
         ::std::mem::size_of::<SECItemStr>(),
         24usize,
@@ -41,48 +18,15 @@
         8usize,
         concat!("Alignment of ", stringify!(SECItemStr))
     );
-    assert_eq!(
-        unsafe { ::std::ptr::addr_of!((*ptr).type_) as usize - ptr as usize },
-        0usize,
-        concat!(
-            "Offset of field: ",
-            stringify!(SECItemStr),
-            "::",
-            stringify!(type_)
-        )
-    );
-    assert_eq!(
-        unsafe { ::std::ptr::addr_of!((*ptr).data) as usize - ptr as usize },
-        8usize,
-        concat!(
-            "Offset of field: ",
-            stringify!(SECItemStr),
-            "::",
-            stringify!(data)
-        )
-    );
-    assert_eq!(
-        unsafe { ::std::ptr::addr_of!((*ptr).len) as usize - ptr as usize },
-        16usize,
-        concat!(
-            "Offset of field: ",
-            stringify!(SECItemStr),
-            "::",
-            stringify!(len)
-        )
-    );
 }
 pub type SECItemArray = SECItemArrayStr;
 #[repr(C)]
 #[derive(Debug, Copy, Clone)]
 pub struct SECItemArrayStr {
-    pub items: *mut SECItem,
-    pub len: ::std::os::raw::c_uint,
+    pub _address: u8,
 }
 #[test]
 fn bindgen_test_layout_SECItemArrayStr() {
-    const UNINIT: ::std::mem::MaybeUninit<SECItemArrayStr> = ::std::mem::MaybeUninit::uninit();
-    let ptr = UNINIT.as_ptr();
     assert_eq!(
         ::std::mem::size_of::<SECItemArrayStr>(),
         16usize,
@@ -92,26 +36,6 @@
         ::std::mem::align_of::<SECItemArrayStr>(),
         8usize,
         concat!("Alignment of ", stringify!(SECItemArrayStr))
-    );
-    assert_eq!(
-        unsafe { ::std::ptr::addr_of!((*ptr).items) as usize - ptr as usize },
-        0usize,
-        concat!(
-            "Offset of field: ",
-            stringify!(SECItemArrayStr),
-            "::",
-            stringify!(items)
-        )
-    );
-    assert_eq!(
-        unsafe { ::std::ptr::addr_of!((*ptr).len) as usize - ptr as usize },
-        8usize,
-        concat!(
-            "Offset of field: ",
-            stringify!(SECItemArrayStr),
-            "::",
-            stringify!(len)
-        )
     );
 }
 pub mod _SECStatus {

some things are clearly missing.. and i dunno if its a missing rust-bindgen option or in the llvm build or... but that isnt causing issues with 151. i'll peruse the changelog a bit

esr140 builds fine with llvm21, and the generated nss_prelude.rs is the same as with llvm20. something changed with llvm22...

(In reply to Landry Breuil (:gaston) from comment #4)

esr140 builds fine with llvm21, and the generated nss_prelude.rs is the same as with llvm20. something changed with llvm22...

apparently that's related to rust-bindgen version, according to https://discussion.fedoraproject.org/t/f44-change-proposal-bump-minimum-rust-bindgen-to-v0-72-selfcontained/179475

and nss_prelude.rs comment header says 0.69.something. i'll look at what generates it, and it also seems that the files in beta/m-c have a 0.72 header. last bindgen update was in bug #1985509 for .. 144

my understanding of all this toolchain plumbing is that the bindgen update in bug #1985509 was mostly to include the fix for https://github.com/rust-lang/rust-bindgen/issues/3279 (https://github.com/rust-lang/rust-bindgen/pull/3280), which 'by accident' in turns includes the fix for https://github.com/rust-lang/rust-bindgen/issues/3264 which would seem vaguely related to the issue im seeing i think... emilio, wdyt ?

i'll see if i can backport that to esr140 but i guess there might be dragons there.

as usual, banging rocks together and hoping for sparks...

Flags: needinfo?(emilio)

Yeah it seems you're just seeing https://github.com/rust-lang/rust-bindgen/issues/3264

Backporting the fix should be reasonably safe.

Flags: needinfo?(emilio)

i'm at the point where i have more or less a backport of https://phabricator.services.mozilla.com/D262840 to esr140, i just needed to tweak the dependency from ohttp to bindgen 0.69 (eg apply last chunk of https://github.com/martinthomson/ohttp/commit/a2335b2e7ffb6805206bf8f59a5f60b9e6f98bb4) and at that point i'm fighting a bit with Cargo.lock regeneration.

But at least i know i'm on the right track, because even if my sample (eg nss_prelude.rs) doesn't look exactly the same as the (correct) one generated by bindgen with llvm21, it does contain the defines/symbols that the llvm22 build was complaining about.

bah, i'm now hitting this one:

error[E0080]: attempt to compute `1_usize - 8_usize`, which would overflow
    --> /usr/obj/ports/firefox-esr-140.10.2/build-amd64/x86_64-unknown-openbsd/release/build/gecko-profiler-8a7d8bb9e019d9b2/out/gecko/bindings.rs:1262:11
     |
1262 |         ][::std::mem::size_of::<root::mozilla::UniquePtr>() - 8usize];
     |           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ evaluation of `gecko_bindings::structs::root::_` failed here

that generated file does have the 'generated by rust-bindgen 0.72' header.

the syntax error seems to be in code generated for testing-only, if i drop the code chunk it seems rust code finally builds.

and another failure in skia code, totally unrelated to rust/bindgen i'd guess:

In file included from /usr/obj/ports/firefox-esr-140.10.2/firefox-140.10.2/gfx/skia/skia/modules/skcms/src/skcms_TransformHsw.cc:56:
/usr/obj/ports/firefox-esr-140.10.2/firefox-140.10.2/gfx/skia/skia/modules/skcms/src/Transform_inl.h:160:12: 
    error: use of undeclared identifier '__builtin_ia32_vcvtph2ps256'; did you mean '__builtin_ia32_cvtpd2ps256'? 
160 |     return __builtin_ia32_vcvtph2ps256((I16)half);
|            ^~~~~~~~~~~~~~~~~~~~~~~~~~~ __builtin_ia32_cvtpd2ps256
/usr/local/llvm22/lib/clang/22/include/avxintrin.h:2187:18: note: '__builtin_ia32_cvtpd2ps256' declared here
2187 |   return (__m128)__builtin_ia32_cvtpd2ps256((__v4df) __a);
|                  ^ 

In file included from /usr/obj/ports/firefox-esr-140.10.2/firefox-140.10.2/gfx/skia/skia/modules/skcms/src/skcms_TransformHsw.cc:56:
/usr/obj/ports/firefox-esr-140.10.2/firefox-140.10.2/gfx/skia/skia/modules/skcms/src/Transform_inl.h:160:40:
     error: cannot initialize a parameter of type '__attribute__((__vector_size__(4 * sizeof(double)))) double' (vector of 4 'double' values) with an rvalue of type 'I16' (vector of 8 'int16_t' values) 
160 |     return __builtin_ia32_vcvtph2ps256((I16)half);
|                                        ^~~~~~~~~
2 errors generated.

(In reply to Landry Breuil (:gaston) from comment #10)

and another failure in skia code, totally unrelated to rust/bindgen i'd guess:

In file included from /usr/obj/ports/firefox-esr-140.10.2/firefox-140.10.2/gfx/skia/skia/modules/skcms/src/skcms_TransformHsw.cc:56:
/usr/obj/ports/firefox-esr-140.10.2/firefox-140.10.2/gfx/skia/skia/modules/skcms/src/Transform_inl.h:160:12: 
    error: use of undeclared identifier '__builtin_ia32_vcvtph2ps256'; did you mean '__builtin_ia32_cvtpd2ps256'? 
160 |     return __builtin_ia32_vcvtph2ps256((I16)half);
|            ^~~~~~~~~~~~~~~~~~~~~~~~~~~ __builtin_ia32_cvtpd2ps256
/usr/local/llvm22/lib/clang/22/include/avxintrin.h:2187:18: note: '__builtin_ia32_cvtpd2ps256' declared here
2187 |   return (__m128)__builtin_ia32_cvtpd2ps256((__v4df) __a);
|                  ^ 

In file included from /usr/obj/ports/firefox-esr-140.10.2/firefox-140.10.2/gfx/skia/skia/modules/skcms/src/skcms_TransformHsw.cc:56:
/usr/obj/ports/firefox-esr-140.10.2/firefox-140.10.2/gfx/skia/skia/modules/skcms/src/Transform_inl.h:160:40:
     error: cannot initialize a parameter of type '__attribute__((__vector_size__(4 * sizeof(double)))) double' (vector of 4 'double' values) with an rvalue of type 'I16' (vector of 8 'int16_t' values) 
160 |     return __builtin_ia32_vcvtph2ps256((I16)half);
|                                        ^~~~~~~~~
2 errors generated.

this one should be handled by https://skia-review.googlesource.com/c/skcms/+/1038217, checking.

i have a working 140.10.2 build with llvm 22.1.5, but that still needs a bunch of hacks/tweaks/gory patches in the rusty bits.

the offending generated code in objdir/x86_64-unknown-openbsd/release/build/gecko-profiler-8a7d8bb9e019d9b2/out/gecko/bindings.rs:

1258     #[allow(clippy::unnecessary_operation, clippy::identity_op)]
1259     const _: () = {
1260         [ 
1261             "Size of template specialization: UniquePtr_open0_JSONWriteFunc_DefaultDelete_open1_JSONWriteFunc_close1_close0",
1262         ][::std::mem::size_of::<root::mozilla::UniquePtr>() - 8usize];
1263         [
1264             "Align of template specialization: UniquePtr_open0_JSONWriteFunc_DefaultDelete_open1_JSONWriteFunc_close1_close0",
1265         ][::std::mem::align_of::<root::mozilla::UniquePtr>() - 8usize];
1266     };

it doesnt seem present in https://searchfox.org/firefox-main/source/__GENERATED__/__linux64-opt__/__RUST_BUILD_SCRIPT__/gecko-profiler/gecko/bindings.rs so i dunno where it's coming from... emilio, any idea?

after digging more, a wild guess would be to add mozilla::UniquePtr to https://searchfox.org/firefox-main/source/tools/profiler/rust-api/build.rs#94. trying...

this (on top of the other fixes) for that last breakage allows me to reliably build esr140 with llvm22:

Index: tools/profiler/rust-api/build.rs
--- tools/profiler/rust-api/build.rs.orig
+++ tools/profiler/rust-api/build.rs
@@ -90,6 +90,7 @@ fn generate_bindings() {
         .opaque_type("std::string")
         .opaque_type("std::unique_ptr")
         .opaque_type("mozilla::Maybe")
+        .opaque_type("mozilla::UniquePtr")
         .opaque_type("mozilla::MallocAllocPolicy")
         .opaque_type("mozilla::Variant")
         .opaque_type("mozilla::baseprofiler::UniqueJSONStrings")

Donal, do you think all this jumbo patchset (to build with llvm22) is worth pushing to esr140 or since esr153 is around the corner there's no point ?

i can still attach my patch stack to the bug anyway...

Flags: needinfo?(dmeehan)
Summary: building esr140 with llvm22 fails in rust code with missing structs/symbols/field/defines/types → fix building esr140 with llvm22

ESR153 starts shipping in July, so we're only taking minimal changes on ESR140 at this point

Flags: needinfo?(dmeehan)

here the jumbo patch if other downstreams want to use it, i'll attach the other ones needed on top later on.

Assignee: nobody → landry
Blocks: 1982221
See Also: → 1982221
No longer blocks: 1982221
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: