On Fri, Dec 08, 2023 at 05:26:16PM +0100, Peter Zijlstra wrote: > On Wed, Dec 06, 2023 at 02:59:11PM -0500, Kent Overstreet wrote: > > > I suspect even if the manpower existed to go that route we'd end up > > regretting it, because then the Rust compiler would need to be able to > > handle _all_ the craziness a modern C compiler knows how to do - > > preprocessor magic/devilry isn't even the worst of it, it gets even > > worse when you start to consider things like bitfields and all the crazy > > __attributes__(()) people have invented. > > Dude, clang can already handle all of that. Both rust and clang are > build on top of llvm, they generate the same IR, you can simply feed a > string into libclang and get IR out of it, which you can splice into > your rust generated IR. If only it were that simple :) This is struct definitions we're talking about, not code, so what you want isn't even IR, what you're generating is a memory layout for a type, linked in with all your other type information. And people critize Linux for being a giant monorepo that makes no considerations for making our code reusable in other contexts; clang and LLVM are no different. But that's not really the issue because you're going to need a huge chunk of clang to even parse this stuff, what you really want is a way to invoke clang and dump _type information_ in a standardized, easy to consume way. What you want is actually more akin to the debug info that's generated today. So... yeah, sure, lovely if it existed, but not the world we live in :) (As an aside, I've actually got an outstanding bug filed with rustc because it needs to be able to handle types that are marked both packed and aligned... if anyone in this thread _does_ know some rust compiler folks, we need that for bcachefs on disk format types).
