Closed Bug 1873379 Opened 2 years ago Closed 2 years ago

libc++ 18 appears to cause rust-bindgen problems with tuple definitions

Categories

(Core :: CSS Parsing and Computation, defect)

Product:
Core
Component:
CSS Parsing and Computation
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
123 Branch
Tracking Flags:
Tracking Status
firefox123 --- fixed

People

(Reporter: dimitry, Assigned: emilio)

References

Details

Attachments

(1 file)

Bug 1873379 - Ignore std::tuple harder. r=#style
48 bytes, text/x-phabricator-request
Details | Review

I'm working on integrating libc++ 18 into FreeBSD, and as part of that I try to build as many FreeBSD ports as possible, including the www/firefox port.

That port (currently at firefox 121.0) failed due to a rust compile error in the style lib:

error[E0412]: cannot find type `_Pred` in this scope
     --> /wrkdirs/usr/ports/www/firefox/work/.build/x86_64-unknown-freebsd/release/build/style-864f04db20298021/out/gecko/structs.rs:35683:49
      |
35683 |                 pub _base: root::std::__1::_And<_Pred>,
      |                                                 ^^^^^ not found in this scope
      |
help: you might be missing a type parameter
      |
35682 |             pub struct tuple__EnableUTypesCtor<_Pred> {
      |                                               +++++++

The problem is similar to something fixed for bug 1672273 in https://hg.mozilla.org/mozilla-central/rev/7c551c5379b4, and which was also reported in https://github.com/rust-skia/rust-skia/issues/571: some libc++ bindings cannot be properly processed with rust-bindgen, and this appears to result in incorrect rust code.

Upstream libc++ moved some stuff around in the <tuple> header here: https://github.com/llvm/llvm-project/commit/fcc13c04bbd1489e016a3910eefcefb596001249, which may have further confused rust-bindgen.

As I am not experienced with rust and rust-bindgen, I would like to ask for some help here.

It seems that layout/style/ServoBindings.toml has a few lines specifically handling std::tuple:

opaque-types = [
...
    "std::tuple",
    "std::tuple_.*", # Causes "Cannot find type _Pred in this scope" error on mac, like rust-skia#571
...

but the generated x86_64-unknown-freebsd/release/build/style-864f04db20298021/out/gecko/structs.rs still has a bunch of declarations relating to std::tuple:

            #[repr(C)]
            #[derive(Debug, Copy, Clone)]
            pub struct __tuple_impl {
                pub _address: u8,
            }
            #[repr(C)]
            #[derive(Debug, Copy, Clone)]
            pub struct tuple {
                pub __base_: root::std::__1::tuple__BaseT,
            }
            pub type tuple__BaseT = root::std::__1::__tuple_impl;
            #[repr(C)]
            #[derive(Debug, Copy, Clone)]
            pub struct tuple__IsThisTuple {
                pub _base: root::std::__1::false_type,
            }
            #[repr(C)]
            #[derive(Debug, Copy, Clone)]
            pub struct tuple__EnableUTypesCtor {
                pub _base: root::std::__1::_And<_Pred>,
            }
            #[repr(C)]
            #[derive(Debug, Copy, Clone)]
            pub struct tuple__EnableCtorFromUTypesTuple {
                pub _base: root::std::__1::false_type,
            }
            #[repr(C)]
            #[derive(Debug, Copy, Clone)]
            pub struct tuple__CtorPredicateFromPair {
                pub _base: root::std::__1::false_type,
            }
            #[repr(C)]
            #[derive(Debug, Copy, Clone)]
            pub struct tuple__EnableCtorFromPair {
                pub _base: root::std::__1::tuple__CtorPredicateFromPair,
            }
            #[repr(C)]
            #[derive(Debug, Copy, Clone)]
            pub struct tuple__NothrowConstructibleFromPair {
                pub _base: root::std::__1::tuple__CtorPredicateFromPair,
            }
            #[repr(C)]
            #[derive(Debug, Copy, Clone)]
            pub struct tuple__BothImplicitlyConvertible {
                pub _base: root::std::__1::false_type,
            }
            pub mod __variant_detail {
                #[allow(unused_imports)]
                use self::super::super::super::super::root;
            }

If somebody can tell me how to exclude or avoid these, or whether I should take this to the rust and/or rust-bindgen people, please let me know.

Hey! I'm testing libc++ 18 with Gentoo currently and I ran across this as well. I'm not sure if this is a proper fix (in fact I doubt it) but here's what I did that appeared to fix it:

--- a/layout/style/ServoBindings.toml
+++ b/layout/style/ServoBindings.toml
@@ -389,6 +389,7 @@ opaque-types = [
                             # for clang.
     "mozilla::SeenPtrs",
     "mozilla::SupportsWeakPtr",
+    "std::__1::_And",
     "std::tuple",
     "std::tuple_.*", # Causes "Cannot find type _Pred in this scope" error on mac, like rust-skia#571
     "SupportsWeakPtr",

I'm actually wondering why the bindings don't dump the whole std:: namespace into the exclude-list. Does the rust code ever need to look into the guts of any STL container?

Hey chutten, it looks like you last touched this code in bug 1672273. Do you have any idea where this should live?

Flags: needinfo?(chutten)
See Also: → 1874059

This is deeper magic than that with which I'm familiar, I'm afraid. Random guess: Maybe the __1 inline namespace is tripping up bindgen? I troubled Emilio for the review when I added the exclusion, maybe he has more knowledge about this?

Flags: needinfo?(chutten) → needinfo?(emilio)

Could you attach the whole generated file? That'd be useful to know where that is coming from.

Component: General → CSS Parsing and Computation
Flags: needinfo?(emilio) → needinfo?(dimitry)
Product: Firefox → Core

In libc++ 18 it seems to be in a nested namespace. Make sure to account
for that.

Assignee: nobody → emilio
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true

Please confirm the attached patch also fixes your issue.

I'm testing this currently, but it may take some time as my ports build machine is a little overloaded.

Severity: -- → S3

Okay, it seems to have built the style crate successfully now:

     Running `CARGO=/usr/local/bin/cargo CARGO_CRATE_NAME=style CARGO_MANIFEST_DIR=/wrkdirs/usr/ports/www/firefox/work/firefox-121.0.1/servo/components/style CARGO_PKG_AUTHORS='The Servo Project Developers' CARGO_PKG_DESCRIPTION='' CARGO_PKG_HOMEPAGE='' CARGO_PK
G_LICENSE=MPL-2.0 CARGO_PKG_LICENSE_FILE='' CARGO_PKG_NAME=style CARGO_PKG_README=README.md CARGO_PKG_REPOSITORY='' CARGO_PKG_RUST_VERSION='' CARGO_PKG_VERSION=0.0.1 CARGO_PKG_VERSION_MAJOR=0 CARGO_PKG_VERSION_MINOR=0 CARGO_PKG_VERSION_PATCH=1 CARGO_PKG_VERSION_
PRE='' LD_LIBRARY_PATH='/wrkdirs/usr/ports/www/firefox/work/.build/release/deps:/usr/local/lib' OUT_DIR=/wrkdirs/usr/ports/www/firefox/work/.build/x86_64-unknown-freebsd/release/build/style-61184c32d8178781/out /usr/local/bin/rustc --crate-name style --edition=2
018 servo/components/style/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type lib --emit=dep-info,metadata,link -C opt-level=2 -C panic=abort -C embed-bitcode=no --cfg 'feature="bindgen"' --cfg 'feature="gecko"' --c
fg 'feature="mozbuild"' --cfg 'feature="nsstring"' --cfg 'feature="regex"' --cfg 'feature="serde"' --cfg 'feature="toml"' -C metadata=895d0aa8ec239640 -C extra-filename=-895d0aa8ec239640 --out-dir /wrkdirs/usr/ports/www/firefox/work/.build/x86_64-unknown-freebsd
/release/deps --target x86_64-unknown-freebsd -C linker=/wrkdirs/usr/ports/www/firefox/work/firefox-121.0.1/build/cargo-linker -L dependency=/wrkdirs/usr/ports/www/firefox/work/.build/x86_64-unknown-freebsd/release/deps -L dependency=/wrkdirs/usr/ports/www/firef
ox/work/.build/release/deps --extern app_units=/wrkdirs/usr/ports/www/firefox/work/.build/x86_64-unknown-freebsd/release/deps/libapp_units-35d20f60d1d60f14.rmeta --extern arrayvec=/wrkdirs/usr/ports/www/firefox/work/.build/x86_64-unknown-freebsd/release/deps/lib
arrayvec-c1e0077560de52e5.rmeta --extern atomic_refcell=/wrkdirs/usr/ports/www/firefox/work/.build/x86_64-unknown-freebsd/release/deps/libatomic_refcell-e03844377c921216.rmeta --extern bitflags=/wrkdirs/usr/ports/www/firefox/work/.build/x86_64-unknown-freebsd/re
lease/deps/libbitflags-ed6d3a24b3af6cea.rmeta --extern byteorder=/wrkdirs/usr/ports/www/firefox/work/.build/x86_64-unknown-freebsd/release/deps/libbyteorder-6f7894671a97197e.rmeta --extern cssparser=/wrkdirs/usr/ports/www/firefox/work/.build/x86_64-unknown-freeb
sd/release/deps/libcssparser-d500c2b1b2a17b7f.rmeta --extern derive_more=/wrkdirs/usr/ports/www/firefox/work/.build/x86_64-unknown-freebsd/release/deps/libderive_more-d5a62e3175eae583.rmeta --extern dom=/wrkdirs/usr/ports/www/firefox/work/.build/x86_64-unknown-f
reebsd/release/deps/libdom-f52d42934133964c.rmeta --extern euclid=/wrkdirs/usr/ports/www/firefox/work/.build/x86_64-unknown-freebsd/release/deps/libeuclid-05d3c04f5b679e55.rmeta --extern fxhash=/wrkdirs/usr/ports/www/firefox/work/.build/x86_64-unknown-freebsd/re
lease/deps/libfxhash-9b47a5b33add78f6.rmeta --extern gecko_profiler=/wrkdirs/usr/ports/www/firefox/work/.build/x86_64-unknown-freebsd/release/deps/libgecko_profiler-4a2369f607af6285.rmeta --extern indexmap=/wrkdirs/usr/ports/www/firefox/work/.build/x86_64-unknow
n-freebsd/release/deps/libindexmap-f4ddc9ba4b6197f6.rmeta --extern itertools=/wrkdirs/usr/ports/www/firefox/work/.build/x86_64-unknown-freebsd/release/deps/libitertools-fb3ebf9a3c2c2949.rmeta --extern itoa=/wrkdirs/usr/ports/www/firefox/work/.build/x86_64-unknow
n-freebsd/release/deps/libitoa-50a74b4ffd8db7c1.rmeta --extern lazy_static=/wrkdirs/usr/ports/www/firefox/work/.build/x86_64-unknown-freebsd/release/deps/liblazy_static-63c6da530f113d46.rmeta --extern log=/wrkdirs/usr/ports/www/firefox/work/.build/x86_64-unknown
-freebsd/release/deps/liblog-78ec76551d5bd779.rmeta --extern malloc_size_of=/wrkdirs/usr/ports/www/firefox/work/.build/x86_64-unknown-freebsd/release/deps/libmalloc_size_of-bce07193701589e2.rmeta --extern malloc_size_of_derive=/wrkdirs/usr/ports/www/firefox/work
/.build/release/deps/libmalloc_size_of_derive-eecce175ae645efd.so --extern matches=/wrkdirs/usr/ports/www/firefox/work/.build/x86_64-unknown-freebsd/release/deps/libmatches-58e8fdc9fc4a58ca.rmeta --extern debug_unreachable=/wrkdirs/usr/ports/www/firefox/work/.bu
ild/x86_64-unknown-freebsd/release/deps/libdebug_unreachable-65e13936d9171d90.rmeta --extern nsstring=/wrkdirs/usr/ports/www/firefox/work/.build/x86_64-unknown-freebsd/release/deps/libnsstring-8cb50e8cf23727ad.rmeta --extern num_derive=/wrkdirs/usr/ports/www/fir
efox/work/.build/release/deps/libnum_derive-58106cf0c2ec7962.so --extern num_integer=/wrkdirs/usr/ports/www/firefox/work/.build/x86_64-unknown-freebsd/release/deps/libnum_integer-5b986c10a0db9036.rmeta --extern num_traits=/wrkdirs/usr/ports/www/firefox/work/.bui
ld/x86_64-unknown-freebsd/release/deps/libnum_traits-8440e823416b9b03.rmeta --extern num_cpus=/wrkdirs/usr/ports/www/firefox/work/.build/x86_64-unknown-freebsd/release/deps/libnum_cpus-c3cf670ac78104d6.rmeta --extern owning_ref=/wrkdirs/usr/ports/www/firefox/wor
k/.build/x86_64-unknown-freebsd/release/deps/libowning_ref-4b4abda8f95d841d.rmeta --extern parking_lot=/wrkdirs/usr/ports/www/firefox/work/.build/x86_64-unknown-freebsd/release/deps/libparking_lot-821ca080bc8a7532.rmeta --extern precomputed_hash=/wrkdirs/usr/por
ts/www/firefox/work/.build/x86_64-unknown-freebsd/release/deps/libprecomputed_hash-63299ffbb3b7258d.rmeta --extern rayon=/wrkdirs/usr/ports/www/firefox/work/.build/x86_64-unknown-freebsd/release/deps/librayon-54d95ebee127c1b5.rmeta --extern rayon_core=/wrkdirs/u
sr/ports/www/firefox/work/.build/x86_64-unknown-freebsd/release/deps/librayon_core-0a0a705312509068.rmeta --extern selectors=/wrkdirs/usr/ports/www/firefox/work/.build/x86_64-unknown-freebsd/release/deps/libselectors-7e4772dea4b2c19f.rmeta --extern serde=/wrkdir
s/usr/ports/www/firefox/work/.build/x86_64-unknown-freebsd/release/deps/libserde-f5b74d642d0ccc14.rmeta --extern servo_arc=/wrkdirs/usr/ports/www/firefox/work/.build/x86_64-unknown-freebsd/release/deps/libservo_arc-506a8763eee29313.rmeta --extern smallbitvec=/wr
kdirs/usr/ports/www/firefox/work/.build/x86_64-unknown-freebsd/release/deps/libsmallbitvec-4f7ec637a353a9a6.rmeta --extern smallvec=/wrkdirs/usr/ports/www/firefox/work/.build/x86_64-unknown-freebsd/release/deps/libsmallvec-4fbfc3d0e8554cac.rmeta --extern static_
assertions=/wrkdirs/usr/ports/www/firefox/work/.build/x86_64-unknown-freebsd/release/deps/libstatic_assertions-3b7c19f68de70f7e.rmeta --extern static_prefs=/wrkdirs/usr/ports/www/firefox/work/.build/x86_64-unknown-freebsd/release/deps/libstatic_prefs-3edf5939160
97090.rmeta --extern style_derive=/wrkdirs/usr/ports/www/firefox/work/.build/release/deps/libstyle_derive-a1c9daa5dfad2349.so --extern style_traits=/wrkdirs/usr/ports/www/firefox/work/.build/x86_64-unknown-freebsd/release/deps/libstyle_traits-302ebefbc7ec93a6.rm
eta --extern thin_vec=/wrkdirs/usr/ports/www/firefox/work/.build/x86_64-unknown-freebsd/release/deps/libthin_vec-b6596c9f7d3b667a.rmeta --extern time=/wrkdirs/usr/ports/www/firefox/work/.build/x86_64-unknown-freebsd/release/deps/libtime-9b27d70d37ec70c8.rmeta --
extern to_shmem=/wrkdirs/usr/ports/www/firefox/work/.build/x86_64-unknown-freebsd/release/deps/libto_shmem-36968a455a832429.rmeta --extern to_shmem_derive=/wrkdirs/usr/ports/www/firefox/work/.build/release/deps/libto_shmem_derive-57dbb011086a2bad.so --extern ulu
ru=/wrkdirs/usr/ports/www/firefox/work/.build/x86_64-unknown-freebsd/release/deps/libuluru-45f5b119d0b39c78.rmeta --extern unicode_bidi=/wrkdirs/usr/ports/www/firefox/work/.build/x86_64-unknown-freebsd/release/deps/libunicode_bidi-a626520f82f9ca0c.rmeta --extern
 unicode_segmentation=/wrkdirs/usr/ports/www/firefox/work/.build/x86_64-unknown-freebsd/release/deps/libunicode_segmentation-9c1a3554545b592f.rmeta --extern void=/wrkdirs/usr/ports/www/firefox/work/.build/x86_64-unknown-freebsd/release/deps/libvoid-bb36ff692b644
a36.rmeta -C force-frame-pointers=yes --cap-lints warn -Cembed-bitcode=yes -C codegen-units=1`

So I think this patch works, at least for this particular issue. However it failed on a completely different libc++ issue, which I will report separately, after some digging:

/usr/local/bin/clang++15 -std=gnu++17 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fstack-protector-strong -fstack-clash-protection -DLIBICONV_PLUG -isystem /usr/local/include -fno-sized-deallocation -fno-aligned-new -O2 -pipe -O3 -DLIBICONV_PLUG -fstack-protector-str
ong -isystem /usr/local/include -fno-strict-aliasing -DLIBICONV_PLUG -isystem /usr/local/include -fno-exceptions -fPIC -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -fno-math-errno -pipe -O2 -O3 -fno-omit-frame-pointer -funwind-tables -shared -Wl
,-z,defs -Wl,--warn-unresolved-symbols -Wl,--gc-sections -Wl,-h,libxul.so -o libxul.so /wrkdirs/usr/ports/www/firefox/work/.build/toolkit/library/build/libxul_so.list    -pthread -Wl,--as-needed -fstack-protector-strong -fuse-ld=lld -Wl,-z,noexecstack -Wl,-z,tex
t -Wl,-z,relro -Wl,-z,nocopyreloc -Wl,-Bsymbolic-functions -Wl,--build-id=sha1 -fstack-protector-strong -fstack-clash-protection -Wl,-rpath-link,/wrkdirs/usr/ports/www/firefox/work/.build/dist/bin -Wl,-rpath-link,/usr/local/lib  ../../../js/src/build/libjs_stati
c.a ../../../build/pure_virtual/libpure_virtual.a /wrkdirs/usr/ports/www/firefox/work/.build/x86_64-unknown-freebsd/release/libgkrust.a ../../../config/external/gkcodecs/libgkcodecs.so ../../../config/external/lgpllibs/liblgpllibs.so ../../../config/external/sql
ite/libmozsqlite3.so ../../../widget/gtk/mozgtk/libmozgtk.so ../../../widget/gtk/mozwayland/libmozwayland.so -Wl,--version-script,libxul.so.symbols  -L/usr/local/lib -licui18n -L/usr/local/lib -licuuc -licudata -laom -ldav1d -lX11 -lXcomposite -lXdamage -lXext -
lXfixes -lXrandr -lXrender -lpthread -lffi -lplds4 -lplc4 -lnspr4 -pthread -ldl -L/lib -lz -lm -lnss3 -lsmime3 -lssl3 -lnssutil3 -lfreetype -lfontconfig -lgdk-3 -lharfbuzz -lpangocairo-1.0 -lpango-1.0 -lgtk-3 -latk-1.0 -lcairo -lcairo-gobject -lgdk_pixbuf-2.0 -l
glib-2.0 -lintl -lgobject-2.0 -lgio-2.0 -lutil -lpng16 -lwebp -lwebpdemux -lgraphite2 -levent -lvpx -lpixman-1 -ldbus-1 -lxcb-shm -lX11-xcb -lxcb -lXcursor -lXi
ld.lld: error: undefined hidden symbol: std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>::operator=(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>> const&)
>>> referenced by Unified_cpp_xpcom_build0.cpp
>>>               /wrkdirs/usr/ports/www/firefox/work/.build/toolkit/library/build/../../../xpcom/build/Unified_cpp_xpcom_build0.o:(NS_InitXPCOM)
>>> referenced by Unified_cpp_xpcom_build0.cpp
>>>               /wrkdirs/usr/ports/www/firefox/work/.build/toolkit/library/build/../../../xpcom/build/Unified_cpp_xpcom_build0.o:(NS_InitXPCOM)
>>> referenced by DataChannel.cpp
>>>               /wrkdirs/usr/ports/www/firefox/work/.build/toolkit/library/build/../../../netwerk/sctp/datachannel/DataChannel.o:(mozilla::DataChannelConnection::SetSignals(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>> const&))
>>> referenced 262 more times

@Violet, if you are able to verify whether the patch also fixes the style build issue for you, let's consider this issue fixed?

Flags: needinfo?(dimitry)

Yeah I'll land the patch as soon as it gets some eyes

Pushed by ealvarez@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/9e96d1447f6c Ignore std::tuple harder. r=firefox-style-system-reviewers,zrhoffman

https://hg.mozilla.org/mozilla-central/rev/9e96d1447f6c

Status: ASSIGNED → RESOLVED
Closed: 2 years ago
status-firefox123: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 123 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: