MSRV 1.61 -> 1.63 #1902
Merged
MSRV 1.61 -> 1.63 #1902
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
We're seeing more of our deps move to this MSRV or higher (e.g. `webpki`, `rustls-platform-verifier`) and it's shipped in Debian stable. Time to move our MSRV to 1.63.
Of the form: ``` error: unnecessary closure used with `bool::then` --> rustls/src/tls13/mod.rs:42:9 | 42 | / (prev.common.hash_provider.algorithm() == self.common.hash_provider.algorithm()) 43 | | .then(|| prev) | |______________------------^ | | | help: use `then_some(..)` instead: `then_some(prev)` | = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#unnecessary_lazy_evaluations = note: `-D clippy::unnecessary-lazy-evaluations` implied by `-D warnings` = help: to override `-D warnings` add `#[allow(clippy::unnecessary_lazy_evaluations)]` ```
|
I think we can/should postpone this until we make a rustls-webpki release? |
I thought updating to aws-lc-rs 1.7.0 merited waiting, but bumping the MSRV ahead of that seems OK to me. |
|
(I'm in no rush either way, just explaining my thinking) |
|
Ah yeah, we're going to take aws-lc-rs 1.7 here too so we'll need this? That makes sense. |
djc
approved these changes
Apr 18, 2024
Yeah I think it's worthwhile for the |
Benchmark resultsInstruction countsSignificant differencesThere are no significant instruction count differences Other differencesClick to expand
Wall-timeSignificant differencesThere are no significant wall-time differences Other differencesClick to expand
Additional informationCheckout details:
|
|
Related question: what do we think about taking dev dependencies that have aggressively very recent MSRVs? I know that is not related to our crate's published MSRV -- it's more about how OK it is to require contributors take toolchain updates. |
I don't perceive a lot of friction using different toolchains when contributing to projects. It seems like there's an existing expectation developers have access to a nightly toolchain for various small tasks. E.g. in rustls-ffi it's required for |
ctz
approved these changes
Apr 18, 2024
I pretty much exclusively use stable and usually update on the day of release. I don't think it's a big deal? Did you run into it anywhere? I know clap is pretty trigger-happy about MSRV bumps, I've given the maintainer a bunch of feedback about it. |
Going to merge this now that the 0.23.5 release is out. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We're seeing more of our deps move to this MSRV or higher (e.g.
webpki,rustls-platform-verifier) and it's shipped in Debian stable. Time to move our MSRV to 1.63.