On Tue, Mar 18, 2025 at 2:53 AM Alistair Francis <alistair23@xxxxxxxxx> wrote: > > On Tue, Jan 14, 2025 at 4:02 PM Alistair Francis <alistair23@xxxxxxxxx> wrote: > > > > On Tue, Jan 7, 2025 at 9:48 PM Andreas Hindborg <a.hindborg@xxxxxxxxxx> wrote: > > > > > > Thanks! Since Gary just sent v2 of the LTO patch [1], could you rebase > > > on that and list it as a dependency? If you are using b4 there is a nice > > > > I can't get Gary's series to apply on rust-next (it does apply on > > master though). > > > > I might just wait until Gary's series gets picked up to rust-next as > > there is already a lot of manual rebasing going on and my series > > currently applies on rust-next. > > > > Unfortunately there are just constant conflicts as the number of > > manual C helpers are continually growing. > > > > Obviously when/if this series is approved I can do a final rebase, I > > would just like to avoid unnecessary churn in the meantime > > Any more thoughts on this? Hi Alistair, I can't speak for Gary as I don't know what his plans are for that LTO series, but I did review that series and this one, and at first glance the two seem orthogonal. The goal of Gary's series is to LTO C helpers into Rust, while the goal of this series is to machine-generate those helpers. Do I have that right? If yes, I think it's important to think about how the two fit together, at least conceptually. Mechanically I think there's an issue with this trick: #ifdef __BINDGEN__ #define __rust_helper #else #define __rust_helper inline #endif which the LTO series uses to generate Rust stubs for these functions while also keeping them marked inline in LLVM IR/bitcode. That said, I see some discussion of cross-language LTO in "How to handle static inline functions" [1], so maybe there's another way that makes more sense in light of this series. Updating the cover letter to elucidate these details is where I'd suggest you start. Cheers. Tamir [1] https://github.com/rust-lang/rust-bindgen/discussions/2405
