On Sun, 26 Jan 2025 at 09:22, Uros Bizjak <ubizjak@xxxxxxxxx> wrote: > > bindgen ChangeLog does not mention __typeof_unqual__, so I assume that > the support depends on RUSTC_LLVM_VERSION. That seems to be a reasonable assumption. I guess some crazy setup *could* install a bindgen that uses a different llvm version than rustc itself, but that sounds pretty damn broken. Let's add Miguel to the participants. Miguel, see https://lore.kernel.org/all/CAHk-=whddBhfi5DUi370W3pYs+z3r2E7KYuHjwR=a1eRig5Gxg@xxxxxxxxxxxxxx/ for my "this doesn't work" report, and then Uros' suggested fix in https://lore.kernel.org/all/CAFULd4a-2F_zKMeR0Yjo2WhRLmyoOQ1VdR2qdV34BrM-b_cQCQ@xxxxxxxxxxxxxx/ > Does the attached incremental patch work for you? 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 the absence of something _clean_ like that, can we just do it in <linux/compiler-xyz.h> instead? IOW, not use the CONFIG_xyz tests for this at all, but do something like /* * bindgen uses LLVM even if our C compiler is gcc, so we cannot * rely on CONFIG_CC_HAS_TYPEOF_UNQUAL */ #if __clang_major__ >= 19 # define CC_HAS_TYPEOF_UNQUAL 1 #endif in <linux/compiler-clang.h> and the gcc version check for gcc (I don't know when __typeof_unqual__ made it)? This does show that our whole "CC_HAS_XYZ" is kind of broken for the Rust integration in general. Linus
