Bump MSRV to 1.68

[rib]

• Lets us build with cargo ndk 3+

• Lets us remove suppression for false-negative clippy warning about unsafe blocks in unsafe functions

• Should unblock CI for Rework input_events API and expose KeyCharacterMap bindings #102

• 1.68.0 notably also builds the standard library with a newer r25 NDK toolchain which avoids the need for awkward libgcc workarounds, so it's anyway a desirable baseline for Android projects.

[rib]

Cc: @MarijnS95

[MarijnS95]

Is winit 0.29 going to bump to 1.68? CC @kchibisov.

rust-mobile/ndk#407 (comment)

[kchibisov]

I'm not sure, that's too new.

[kchibisov]

Yeah, after checking repology for rust, Debian (even sid) is around 1.64-1.66, so we can't bump past that. 1.65 is the max I'd be comfortable with as of now.

[rib]

1.68 has more significance for Android development I think, so it sounds reasonable that winit wouldn't need to bump its msrv on account of this.

Thankfully we don't have to worry about Debian support here :)

The MSRV policy for this crate currently is supporting stables releases over the last three month window, which currently includes 1.69, but my main interest here was bump to 1.68 specifically, since that release bumped the NDK used by the rust toolchain.

1.68 is now 5 months old, so this is pretty conservative still I'd say.

[MarijnS95]

Since all mainstream tools have a tested and true workaround for "the libgcc.a issue", that should be the least of our worries.

[kchibisov]

I'm just saying that I can't pull 1.68 because alacritty is packaged on debian, and debian is at 1.66 even on sid, so I simply block the bump downstream.

[kchibisov]

If you're interested no how to pick msrv look at https://repology.org/project/rust/versions and https://repology.org/project/alacritty/versions . Clearly only debian blocks and we can't bump because they unlikely to bump.

[kchibisov]

Besides, I understand that for Android it doesn't make any sense and for this crate it's likely fine, but if you want to pull this update into winit soon-ish, you must verify that winit can bump the version, which is why @MarijnS95 pinged me. We can't have different msrvs per different targets in winit, it'll become unmaintainable.

[rib]

Huh, so you're saying that because Debian requires Winit to have an extremely conservative MSRV that now we have to be stuck with that same restriction for Android development - that's silly.

I assumed that Cargo wouldn't care about the MSRV for this crate unless you were building for Android - surely that's the case.

[rib]

Since all mainstream tools have a tested and true workaround for "the libgcc.a issue", that should be the least of our worries.

cargo ndk dropped support for that workaround with 3.0.

Technically we can use an old version of cargo ndk but that's awkward.

[rib]

If you're interested no how to pick msrv look at https://repology.org/project/rust/versions and https://repology.org/project/alacritty/versions . Clearly only debian blocks and we can't bump because they unlikely to bump.

This is really silly though - we're talking about a crate that's only for Android. The release cycle of Linux distros shouldn't be a concern here.

[rib]

Urgh, I didn't think about the fact that the Winit CI is going to build the Android backend with it's MSRV and fail :/

That's really annoying :-(

[kchibisov]

The problem is in rust-version, we can't set it for each target individually, and given that we need to keep it low, it'll sort of blow up.