Am 15.10.2024 um 15:17 hat Paolo Bonzini geschrieben: > This includes a few fixes to the Rust build system machinery, and > removes constructs that were added or stabilized after version 1.63.0:
Most of this series looks harmless in the sense that we need to write some workaround code in a single place and can forget about it. So that's good. > - "let else" (by patching bilge-impl, patch 4; stable in 1.65.0) This one affects all of the code we'll write and the replacement is a bit unwieldy. It might be the most annoying one from the list. > - std::sync::OnceLock (patch 6; stable in 1.70.0) > > - core::ffi (patch 7; stable in 1.64.0) > > - c"" literals (patch 9; stable in 1.77.0) This one will be fairly widespread, too, but only a minor inconvenience. > - offset_of! (patch 10; stable in 1.77.0) Requiring structs to be wrapped in with_offsets! has potential to become quite annoying, too, but it seems we already have a solution for this with the proc macro. > - MaybeUninit::zeroed() (patch 11; stable in 1.75.0 in const context) > > It also replicates the configuration checks normally done by > proc-macro2's build.rs into our Meson-based build rules, so that > the crate can be made to work with an older version of rustc. > > As a small bonus, patch 11 removes some uses of unsafe, so that patch > probably won't just be simply reverted even once we can assume version > 1.75.0 of the language. And as another small bonus this series introduces > the first use of Rust unit tests. > > On top of this, the required version of bindgen is still too new > for Debian 12 and Ubuntu 22.04. This is fixed by the last four patches. > > This is an RFC for two reasons. First, because it would be a valid > decision to delay enabling of Rust until at least some of these > features are available in all supported distros. Another possibility > could be to accept Rust 1.64.0 but require installing a newer bindgen > (0.66.x for example) on those two distros with an older release. Second, > because the series is missing the CI updates to actually ensure that > these minimum versions keep working. > > The main purpose is to show the kind of hacks that would be needed > to support older toolchains. The fixes (for example patches > 1/2/3/6/8/11/13/14) can be easily extracted independent of the outcome > of the discussion, and/or while the CI updates are made. It would probably make sense to just go ahead and apply the fixes. They seem a lot more obvious than the question which toolchains we want to support. Kevin
