Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bump MSRV to Rust 1.38 #877

Merged
merged 3 commits into from
Jul 22, 2022
Merged

Bump MSRV to Rust 1.38 #877

merged 3 commits into from
Jul 22, 2022

Conversation

taiki-e
Copy link
Member

@taiki-e taiki-e commented Jul 22, 2022

It was released nearly 3 years ago and meets our MSRV policy.

This allows using const_in_array_repeat_expressions (rust-lang/rust#49147) and <pointer>.cast().

@taiki-e taiki-e force-pushed the const-in-array-repeat-expressions branch from dc70a29 to 6ac1232 Compare July 22, 2022 13:27
@taiki-e
Copy link
Member Author

taiki-e commented Jul 22, 2022

FYI @cuviper (because this PR affects rayon's MSRV)

Also, aside from this PR, I would like to update our MSRV policy to support 1 year instead of 6 months. Otherwise, it is impossible for rayon to actually maintain their MSRV policy (because our current MSRV policy allows us to increase the MSRV as a minor change).

@taiki-e
Copy link
Member Author

taiki-e commented Jul 22, 2022

bors r+

@bors
Copy link
Contributor

bors bot commented Jul 22, 2022

Build succeeded:

@bors bors bot merged commit c059aec into master Jul 22, 2022
@bors bors bot deleted the const-in-array-repeat-expressions branch July 22, 2022 14:51
bors bot added a commit that referenced this pull request Jul 23, 2022
880: Prepare for the next release r=taiki-e a=taiki-e

- crossbeam-channel 0.5.5 -> 0.5.6
  - Bump the minimum supported Rust version to 1.38. (#877)
- crossbeam-deque 0.8.1 -> 0.8.2
  - Bump the minimum supported Rust version to 1.38. (#877)
- crossbeam-epoch 0.9.9 -> 0.9.10
  - Bump the minimum supported Rust version to 1.38. (#877)
  - Mitigate the risk of segmentation faults in buggy downstream implementations. (#879)
  - Add `{Atomic, Shared}::try_into_owned` (#701)
- crossbeam-queue 0.3.5 -> 0.3.6
  - Bump the minimum supported Rust version to 1.38. (#877)
- crossbeam-utils 0.8.10 -> 0.8.11
  - Bump the minimum supported Rust version to 1.38. (#877)
- crossbeam 0.8.1 -> 0.8.2
  - Bump the minimum supported Rust version to 1.38. (#877)


Co-authored-by: Taiki Endo <te316e89@gmail.com>
@cuviper
Copy link
Contributor

cuviper commented Jul 25, 2022

Thanks for the heads-up. I have no problem with this tiny bump. 🙂

FWIW, I'm looking at 1.56 in rayon-rs/rayon#964, but that will wait a few months yet to meet our 1-year MSRV policy.

@dhardy
Copy link

dhardy commented Aug 3, 2022

FYI this has broken rand's CI (using Rust 1.36). It's not critical since it's only through rand using rayon as a dev-dependency, but still a little annoying seeing a patch release bump the MSRV.

@taiki-e
Copy link
Member Author

taiki-e commented Aug 3, 2022

@dhardy

still a little annoying seeing a patch release bump the MSRV.

We had treated MSRV bump as a major change in the past, but maintaining that policy was a pain for both maintainers and users, so we changed our policy. See #444 (comment) and #503 (comment) for more.

(FYI, rust-lang/libc#2845 and rust-lang/libs-team#72 are the latest discussions on MSRV for crate widely used in the ecosystem. )

It's not critical since it's only through rand using rayon as a dev-dependency

FWIW, AFAIK, dev-deps often have much more lenient MSRV policy than the crate under test, so there are many projects that do not run cargo test on MSRV, but only run cargo build. (e.g., serde, syn, regex, tokio, futures, etc.)

@dhardy
Copy link

dhardy commented Aug 3, 2022

Committing only to support rustc versions no more than 6 months or 1 year old honestly sounds like a sensible option to me. We've seen very little concern about bumping the MSRV of rand in the past.

but still a little annoying seeing a patch release bump the MSRV

Sorry, I shouldn't complain about something already using the best apparent solution!

@tatsuya6502
Copy link

@dhardy

Just FYI. I am not sure if this is the best way, but instead of bumping the MSRV of my library, I have been working around it by pinning dependencies to some older versions in Cargo.lock when testing the MSRV.

moka-rs/moka/blob/78050701a/.github/workflows/CI.yml#L55-L67

      - name: Pin some dependencies to specific versions (MSRV only)
        if: ${{ matrix.rust == '1.51.0' }}
        # hashbrown >= v0.12 requires Rust 2021 edition.
        # native-tls >= v0.2.9 requires more recent Rust version.
        # async-global-executor >= 2.1 requires Rust 2021 edition.
        # pull-down-cmark >= 0.9.2 requires Rust 2021 edition.
        run: |
          cargo update -p dashmap --precise 5.2.0
          cargo update -p indexmap --precise 1.8.2
          cargo update -p hashbrown --precise 0.11.2
          cargo update -p native-tls --precise 0.2.8
          cargo update -p async-global-executor --precise 2.0.4
          cargo update -p pulldown-cmark --precise 0.9.1

bors bot added a commit that referenced this pull request Sep 28, 2022
913: Remove dependency on once_cell and work around windows-gnu LTO issue r=taiki-e a=taiki-e

Replace `once_cell` with our own `OnceLock` that based on unstable `std::sync::OnceLock` due to MSRV issue[^1].

This also fixes #856 due to windows-gnu LTO issue.

[^1]: [The current readme says crossbeam support at least 6 months old compilers](https://github.com/crossbeam-rs/crossbeam/blob/e54f01e7a7e3913407e817ce3e578a76b6392ef1/README.md#compatibility), but that is a minimum guarantee and is [actually more conservative](#877 (comment)).

Co-authored-by: Taiki Endo <te316e89@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

4 participants