This is all very unfortunate, newer versions of Cargo support redox_syscall@0.5.

Truth be told this is somewhat appalling to me. Why would such a foundational crate be bumped to such a relatively recent version of Rust?

AFAIK they don't have a MSRV policy at all.

Poke @jackpot51, would you consider bringing a more conservative MSRV policy into the foundational Redox crates?

What is the desired MSRV?

Softbuffer currently requires v1.70.
But the problem is rather that we need some sort of MSRV policy.

E.g. don't increase the MSRV without a minor version update or something (the policy most crates I know have).

@notgull on that note, I know that all crates in rust-windowing have the same MSRV policy as the one described in Winit, but we should still add that to the README here.

EDIT: Following the MSRV policy of Winit, the next version could be updated to v1.77. But we aren't there yet.

Worth noting that redox_syscall is only useful for compiling for Redox, and Redox is only supporting a specific nightly toolchain at this point in time, nightly-2024-05-11, which identifies itself as rustc 1.80.0-nightly (6e1d94708 2024-05-10).

It is strange to call it "appalling", for a crate that is only designed for use on an operating system that only supports a toolchain newer than Rust 1.77 to use features available in that toolchain.

Can I get some more background on why this was a problem?

It is strange to call it "appalling", for a crate that is only designed for use on an operating system that only supports a toolchain newer than Rust 1.77 to use features available in that toolchain.

I believe that @notgull is terribly passionate about this specific problem. The word "appalling" is a bit strong worded imo.

Can I get some more background on why this was a problem?

The problem is that it breaks our CI and also breaks any promises we make to the user. I entirely forgot that Redox requires nightly, so I agree adding an MSRV policy to redox_syscall really doesn't make any sense.

I think what we need to do is:

1. Don't check MSRV for Redox in our CI.
2. Document en exception for Redox in our MSRV policy, exactly like we do for Android as well.

Thanks @jackpot51.

Yes, please do not check MSRV on Redox, at least until we are able to use a stable compiler.

If redox_syscall is causing MSRV checks to fail on other Operating Systems, that is not desired behavior so please let me know!