On Sun, Jan 26, 2025 at 7:30 PM Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > Let's add Miguel to the participants. Miguel, see > > https://lore.kernel.org/all/CAHk-=whddBhfi5DUi370W3pYs+z3r2E7KYuHjwR=a1eRig5Gxg@xxxxxxxxxxxxxx/ Thanks for the Cc -- I build linux-next with Rust enabled with some configs/compilers/arches variations, and I also have a run using Fedora's latest container image for rust-next, but not the combination of both (and I mostly do Clang builds). I will add a couple distro builds for linux-next in my matrix, one including GCC, so that hopefully at least you don't get blocked with something like this. > for my "this doesn't work" report, and then Uros' suggested fix in > > https://lore.kernel.org/all/CAFULd4a-2F_zKMeR0Yjo2WhRLmyoOQ1VdR2qdV34BrM-b_cQCQ@xxxxxxxxxxxxxx/ RUSTC_LLVM_VERSION is indeed not necessarily bindgen's libclang. One can see the latter's version with: bindgen --version --verbose Though in `scripts/rust_is_available.sh` we use this to support older ones: bindgen scripts/rust_is_available_bindgen_libclang.h 2>&1 | sed -nE 's:.*clang version ([0-9]+\.[0-9]+\.[0-9]+).*:\1:p' So we could easily add a `BINDGEN_LLVM_VERSION` if we go that route. (We also fetch bindgen's Clang version in `rust/Makefile` already to tweak a flag, so this could be useful anyway.) We could also do a `BINDGEN_CLANG_HAS_TYPEOF_UNQUAL`, i.e. mimicking the `CC` one. A bigger hammer is using the `#define` we already pass when using `bindgen`, i.e. `!defined(__BINDGEN__)`, in the source code. I tried this one quickly and seems to work, but we would need it in both places `__CHECKER__` is. > That does seem to work, but I'd admittedly be happier if we could just > find some way to dynamically disable/enable __typeof_unqual__ based on > which compiler is used, rather than make it a config option. So that > bindgen would not see it, but a recent enough C compiler would. > > We already use '__has_attribute()' for some of these things. There's a > '__has_extension()' thing that comes from clang but that gcc also > supports. > > But I can't find the list of extensions that that model supports, and > I guess typeof_unqual isn't on that list if I find it. In LLVM it seems to be at `clang/include/clang/Basic/Features.def`, but from a quick look at that and the commits that added `typeof_unqual` I don't see it (but it seems it could have been there, indeed, given other keywords are listed there): https://github.com/llvm/llvm-project/blob/main/clang/include/clang/Basic/Features.def In GCC I see a few at `gcc/c-family/c-common.cc` (`has_feature_table`) and `gcc/c/c-objc-common.cc` (`c_feature_table`). I can't see `typeof_unqual`. > This does show that our whole "CC_HAS_XYZ" is kind of broken for the > Rust integration in general. Yes, bindgen being libclang-only is one of the main reasons why we call GCC builds with Rust enabled "very experimental" (and why Rust doesn't work with GCC's randstruct plugin and things like that). Ideally bindgen would have a way to parse code using GCC (https://github.com/rust-lang/rust-bindgen/issues/1949), or perhaps it could fetch layout information in a completely different way, e.g. building a C file that computes it. There have been some discussions and even some code written about this over the years, but so far nothing really usable yet. Cheers, Miguel
