Switch to stable Rust toolchain

[rinon]

Ideally rav1d should build with a stable toolchain at some point. It looks like we ended up with a few nightly-only features from the initial c2rust transpile that we should eventually remove. I currently find three nightly-only features that we use:

• core_intrinsics: Replace remaining C atomic intrinsics with native Rust atomics #688, #![feature(core_intrinsics)]: Remove as it's unused #745
• c_variadic: #![feature(c_variadic)]: Remove for the rav1d library #620
• extern_types: #![feature(extern_types)]: Remove for the rav1d library #593

The intrinsics we can take care of by using stabilized Rust atomic types, the variadic usage appears to just be vfprintf which would be easy to remove, and for extern types we can probably do opaque pointers in another way.

[kkysen]

The extern types might be all gone now after we deduplicated everything. At least the rav1d library; the few binaries still have a bunch that are hard to unravel due to type erasure generics.

[kkysen]

I've been meaning to fix all the atomic intrinsics to use atomic types soon; that'll be part of making the core data types safe.

[kkysen]

For the variadics, I'm not sure we can fully get rid of those because there are callbacks the user can set and we need to keep that ABI. Eventually we can put it behind a legacy C API feature flag, as we shouldn't need it for pure Rust usage.

[rinon]

The extern types might be all gone now after we deduplicated everything. At least the rav1d library; the few binaries still have a bunch that are hard to unravel due to type erasure generics.

Could we do the same thing as bindgen and make the type unconstructable? We don't care what it's purported layout is, only that we can't construct it.

I've been meaning to fix all the atomic intrinsics to use atomic types soon; that'll be part of making the core data types safe.

Do we have an issue on this? I was just looking at that, will simplify some things nicely.

For the variadics, I'm not sure we can fully get rid of those because there are callbacks the user can set and we need to keep that ABI. Eventually we can put it behind a legacy C API feature flag, as we shouldn't need it for pure Rust usage.

Eek ok, yeah. This whole issue is super low priority, I just wanted to create an issue on it while I was thinking about it.

[kkysen]

Could we do the same thing as bindgen and make the type unconstructable? We don't care what it's purported layout is, only that we can't construct it.

I'm not sure, but the binaries I don't think are very important compared to the rav1d library that others will use. And there are Rust libraries we can use for the demuxing in those binaries instead if we want to make them safe, sidestepping the issue. But I don't think people depend on these binaries (except our tests I guess), so it's a very low priority.

I've been meaning to fix all the atomic intrinsics to use atomic types soon; that'll be part of making the core data types safe.

Do we have an issue on this? I was just looking at that, will simplify some things nicely.

No, I don't think so. Feel free to open one.

Eek ok, yeah. This whole issue is super low priority, I just wanted to create an issue on it while I was thinking about it.

👍

[thedataking]

But I don't think people depend on these binaries (except our tests I guess), so it's a very low priority.

Exactly. If the Rust binaries give us any trouble, I think we can delete them and build the C sources with meson. I have a patch somewhere to do that already – that's one way to test that we remain C compatible.

[kkysen]

Exactly. If the Rust binaries give us any trouble, I think we can delete them and build the C sources with meson. I have a patch somewhere to do that already – that's one way to test that we remain C compatible.

I'm not sure if we should fully delete them in case someone finds them useful for a rust version of them, but I'd be in favor of testing with the C versions of them (though it does complicate the build system, unfortunately).

[kkysen]

With #688 fixing #638, we can remove #![feature(core_intrinsics)] now.

[negge]

Is the minimum rust version documented anywhere in the project? I could not get rav1d main to compile with 1.76.0-nightly on aarch64.

[kkysen]

Is the minimum rust version documented anywhere in the project? I could not get rav1d main to compile with 1.76.0-nightly on aarch64.

Hi! Yes, we have our nightly pinned in rust-toolchain.toml. cargo should use it automatically. How are you trying to build rav1d?

We can remove the last nightly feature, but it wasn't a priority, so we haven't done it quite yet. Once we do, we'll switch to stable.

[negge]

Hi! Yes, we have our nightly pinned in rust-toolchain.toml. cargo should use it automatically. How are you trying to build rav1d?

I filed issue #773 with the exact build command. Just a simple cargo build --release.

[kkysen]

With #620, we'll be able to build rav1d on stable, with the following exceptions:

• We're currently using #![feature(pointer_is_aligned)] because it is stabilized in 1.79 in stabilize ptr.is_aligned, move ptr.is_aligned_to to a new feature gate rust-lang/rust#121948, and our nightly-2024-04-01 is new enough that it's already stable there. 1.79 releases on 2024-06-13, in 3 weeks, so that'll be fine.
• On target_arch = "arm", we use #![feature(stdarch_arm_feature_detection)] (tracked in Tracking Issue for stdarch_arm_feature_detection rust-lang/rust#111190).
• On target_arch = "riscv32" and target_arch = "riscv64", we use #![feature(stdarch_riscv_feature_detection)] (tracked in Tracking Issue for stdarch_riscv_feature_detection rust-lang/rust#111192).
• The non-rav1d library binaries, dav1d and seek_stress, still use unstable features, and we don't intend on fixing that. We only care about building rav1d itself on stable, but having those other binaries in the crate does mean we can't just put channel = "stable" in the rust-toolchain.toml.

For #![feature(stdarch_arm_feature_detection)] and #![feature(stdarch_riscv_feature_detection)], I'm not sure if those will be stabilized soon, but it still seems better to do it with this officially supported way than the dav1d way of manually detecting CPU features.

It would be nice if we can get rust_toolchain.toml to use channel = "stable" only for rav1d and for x86, x86_64, and aarch64.

[rinon]

I'm gonna do a quick fix up on the tools so we can be on stable.

[kkysen]

I'm gonna do a quick fix up on the tools so we can be on stable.

I'm not sure it's so simple to get rid of #![feature(extern_types)] since the types are different in different modules.