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.