New patch versions bring new toolchain requirements

[hug-dev]

Hello 👋

We are using some of the picky crates in our various Parsec projects. For the second time we noticed that a new patch version of one of the crate introduced code only compiling on the latest stable.
The specific case here is the switch of picky-asn1 from 0.3.1 to 0.3.2. The later requires Rust version 1.52.0 to compile.

We had 0.3.1 in our Cargo.toml and with a cargo update it fetched 0.3.2 as per semver rules and broke compilation in some places where the Rust version was specifically fixed to an older version.

This is mostly open for discussion: what are your opinions on this? Are semver rules concerned about Rust versions as well? Would it make sense to introduce a Minimum Stable Rust Version?

[CBenoit]

Hi! 👋

Oh, I didn't notice minimal rustc version was bumped in a patch version… I'm sorry to hear it caused troubles on your side 😕

To be honest, I'm not a hardliner on this matter. I personally always work on latest stable (or sometimes nightly) and rustc updates are retro-compatibles, so I don't see this as a breaking change as no code needs to be changed. However, I'm aware that in some environments this can indeed becomes a nuisance if newer rustc binaries are not available. At least, I'm totally in favor of not bumping minimal stable rust version for patch because these tend to be updated automatically by semver rules.

I won't guarantee a minimum stable Rust version, but at least I'll try to make sure to not accidentally raise the minimum when updating patch number and try to be more aware about it. Next time minimum required version bumps I'll make sure to increase minor number instead (including for pre-1.0.0 releases like picky-asn1) and document that in the changelog file.
In other words, you should now consider yourself safe when running cargo update with picky crates version pinned by minor number.

Just for my own information, what is the version you are able to build now?

[hug-dev]

At least, I'm totally in favor of not bumping minimal stable rust version for patch because these tend to be updated automatically by semver rules.

Agree with that too! That would make things easier. I guess in the long run it's not maintainable to keep the same rustc version for a long time and having to release a breaking version just for that is a bit annoying. Maybe the main thing is not too use features of Rust that are too new?

In other words, you should now consider yourself safe when running cargo update with picky crates version pinned by minor number.

Perfect 👌!

Just for my own information, what is the version you are able to build now?

We use the following:

picky-asn1-der = { version = "<=0.2.4", optional = true }
picky-asn1 = { version = ">=0.3.1, <=0.3.1", optional = true }
picky-asn1-x509 = { version = "0.4.0", optional = true }

[CBenoit]

Thank you!

Maybe the main thing is to not use features of Rust that are too new?

Yes, I tend to prefer newer features if it helps improving code maintenance but I'll encourage to not bump minimal rustc version for something that could be equally good without (picky doesn't really requires recent features to be honest).

Also, I would like to know a bit more about your situation. What prevents you from using latest stable and what is the timing for updates? Is this because you use system package manager? Is this because of CI constraint?

By the way, I investigated a bit more about the recent rustc version bump

error[E0658]: use of unstable library feature 'assoc_char_funcs': recently added
   --> picky-asn1/src/restricted_string.rs:268:9
    |
268 |         char::decode_utf16(u16_it).all(|c| matches!(c, Ok(_)))
    |         ^^^^^^^^^^^^^^^^^^
    |
    = note: see issue #71763 <https://github.com/rust-lang/rust/issues/71763> for more information

error: aborting due to previous error

It's actually not using anything fancy, code can be made to compile for rustc 1.43 just by writing core::char::decode_utf16 instead.
I'll yank picky-asn1 0.3.2 and publish picky-asn1 0.3.3 so you can update without trouble.

I'll be checking minimal rustc version with the 1.49 stable toolchain for all picky crates because a transitive dependency of picky is using "Union initialization and Drop" feature available with this release.

[hug-dev]

Great, I believe that was this exact line that caused the initial problem.

What prevents you from using latest stable and what is the timing for updates? Is this because you use system package manager? Is this because of CI constraint?

We want Parsec to be packaged and available in Linux distributions where they use a Rust version older than the latest stable 😕 The version requirement comes from openSUSE Leap where the available version is 1.43.0. Because of that, we try as much as possible to make Parsec compile for that version. I believe that we will be able to bump our minimum Rust version whenever there is an update of the packaged Rust there.

[CBenoit]

Oh I understand! I can't do much for picky crate because we need aes-gcm which currently requires at least rustc 1.49 (because of polyval), but I think it's fairly easy to support rustc 1.43 for the others, I'll keep a 1.43 stable toolchain installed on my machine 🙂

[hug-dev]

Awesome, thank you for the effort 👍

[CBenoit]

Quick follow up: this PR adds a CI check for minimal supported rust version of all our published crates 😄