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

toolchain: update to Rust 1.68.0 #8721

Merged
merged 2 commits into from
Mar 14, 2023
Merged

Conversation

jakmeier
Copy link
Contributor

@jakmeier jakmeier commented Mar 14, 2023

Routine update to the latest version of Rust.
Release post: https://blog.rust-lang.org/2023/03/09/Rust-1.68.0.html

I don't see anything exciting for nearcore in the release.
Maybe pin! for custom futures could be useful.

The commit also includes clippy changes, they renamed
derive_hash_xor_eq to derived_hash_with_manual_eq
and changed the check. Now, we no longer need an allow().

There is also a new future incompatibility warning
which we hit in fs_extra v1.2.0 and wasmparser v0.78.2.
I don't think we can get rid of the second anytime soon, assuming we
hang on to replayability.

Routine update to the latest version of Rust.
Release post: https://blog.rust-lang.org/2023/03/09/Rust-1.68.0.html

I don't see anything exciting for nearcore in the release.
Maybe `pin!` for custom futures could be useful.

The commit also includes clippy renaming `derive_hash_xor_eq`
to `derived_hash_with_manual_eq`.

There is also a new [future incompatibility warning](rust-lang/rust#103418)
which we hit in `fs_extra v1.2.0` and `wasmparser v0.78.2`.
I don't think we can get rid of the second anytime soon, assuming we
hang on to replayability.
@@ -160,7 +160,7 @@ impl PublicKey {

// This `Hash` implementation is safe since it retains the property
// `k1 == k2 ⇒ hash(k1) == hash(k2)`.
#[allow(clippy::derive_hash_xor_eq)]
#[allow(clippy::derived_hash_with_manual_eq)]
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This, I believe, should no longer be necessary, as the rename is a part of the changes that now allow manual implementation of hash regardless of how the Eq implementation is produced.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ahh, yes makes sense. Removed them.

@jakmeier jakmeier marked this pull request as ready for review March 14, 2023 10:46
@jakmeier jakmeier requested a review from a team as a code owner March 14, 2023 10:46
@jakmeier jakmeier requested review from nikurt and nagisa March 14, 2023 10:46
@jakmeier
Copy link
Contributor Author

I've added #8723 for the future incompatibility issue. @nagisa I would appreciate your input on that issue if you have anything to add.

@near-bulldozer near-bulldozer bot merged commit cbdefe5 into near:master Mar 14, 2023
@jakmeier jakmeier deleted the rust-1.68.0 branch March 14, 2023 11:03
nikurt pushed a commit to nikurt/nearcore that referenced this pull request Mar 15, 2023
Routine update to the latest version of Rust.
Release post: https://blog.rust-lang.org/2023/03/09/Rust-1.68.0.html

I don't see anything exciting for nearcore in the release.
Maybe `pin!` for custom futures could be useful.

The commit also includes clippy changes, they renamed 
`derive_hash_xor_eq` to `derived_hash_with_manual_eq`
and changed the check. Now, we no longer need an `allow()`.

There is also a new [future incompatibility warning](rust-lang/rust#103418)
which we hit in `fs_extra v1.2.0` and `wasmparser v0.78.2`.
I don't think we can get rid of the second anytime soon, assuming we
hang on to replayability.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants