Fix Redox MSRV CI

[daxpedda]

Apparently redox_syscall v0.5.3 now requires Rust v1.77.

[daxpedda]

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

[notgull]

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?

[daxpedda]

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

[notgull]

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

[jackpot51]

What is the desired MSRV?

[daxpedda]

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.

[jackpot51]

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?

[daxpedda]

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.

[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!

[MarijnS95]

Side-question: it seems softbuffer is set to squash-merge without any context/description in the commit messages?

[daxpedda]

Side-question: it seems softbuffer is set to squash-merge without any context/description in the commit messages?

By default it inserts one, I just deleted it on purpose for this commit.

[MarijnS95]

By default it inserts one, I just deleted it on purpose for this commit.

For git log purposes I feel like Fix Redox MSRV CI on its own is pretty "useless" context. Adding a simple sentence like Downgrade redox to 0.5.2 to opt out of 1.77 MSRV similar to what you wrote in the description goes a long way... But that's for next time :)