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 to Rust 1.82 #2001

Open
wants to merge 4 commits into
base: master
Choose a base branch
from
Open

Bump to Rust 1.82 #2001

wants to merge 4 commits into from

Conversation

coolreader18
Copy link
Collaborator

Description of Changes

This was discussed as something we wanted to do before the 1.0 release.

Expected complexity level and risk

1

cc @clockworklabs/devops

Copy link
Contributor

@gefjon gefjon left a comment

Choose a reason for hiding this comment

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

Please don't include unrelated changes in PRs like this. As a reviewer, I don't want to sort through what changed as a result of bumping to the new Rust version versus what drive-by fixes you made. If you feel that the unrelated changes are worthwhile (all of them look good to me), please open a separate PR. I would approve "reformat doc comments to correctly indent multi-line list items" in a heartbeat, for example.

crates/bindings-sys/src/lib.rs Show resolved Hide resolved
crates/bindings-sys/src/lib.rs Show resolved Hide resolved
crates/bindings/src/logger.rs Show resolved Hide resolved
crates/bindings/src/rt.rs Show resolved Hide resolved
crates/client-api-messages/src/name/tests.rs Show resolved Hide resolved
crates/table/src/bflatn_from.rs Show resolved Hide resolved
crates/table/src/eq.rs Show resolved Hide resolved
crates/table/src/eq_to_pv.rs Show resolved Hide resolved
crates/table/src/page.rs Show resolved Hide resolved
crates/table/src/row_hash.rs Show resolved Hide resolved
@coolreader18
Copy link
Collaborator Author

All the changes are fixing warnings that were added sometime in the past 4 versions. That's one of the benefits of keeping up to date with stable rust; less churn in updating wrt rustc/clippy warnings (perhaps we could run CI clippy on latest stable?). The doc-comment formatting changes are all related to a new lint complaining about lists not being indented correctly, and all the cfg-related changes are related to the new check-cfgs lint, that makes sure you don't accidentally typo to e.g. a feature that doesn't exist (as in a couple cases here). And yes, rustc's unused-detection was improved, I think to check for when something declared pub isn't actually publically exposed or used anywhere in the crate. The mem::transmute thing is from a new clippy lint requiring that you specify the T, U type parameters, which I'd agree is definitely best practice - makes it easy to see at a glance what the conversion actually is, instead of having to trace the type inference yourself (or to be using an IDE).

@gefjon
Copy link
Contributor

gefjon commented Nov 22, 2024

That's one of the benefits of keeping up to date with stable rust; less churn in updating wrt rustc/clippy warnings (perhaps we could run CI clippy on latest stable?).

Running Clippy on latest stable seems eminently reasonable. Updating our MSRV every month does not. It is very much the point of a Minimum Supported Rust Version that it should be the lowest possible version.

The doc-comment formatting changes are all related to a new lint complaining about lists not being indented correctly, and all the cfg-related changes are related to the new check-cfgs lint, that makes sure you don't accidentally typo to e.g. a feature that doesn't exist (as in a couple cases here). And yes, rustc's unused-detection was improved, I think to check for when something declared pub isn't actually publically exposed or used anywhere in the crate. The mem::transmute thing is from a new clippy lint requiring that you specify the T, U type parameters, which I'd agree is definitely best practice - makes it easy to see at a glance what the conversion actually is, instead of having to trace the type inference yourself (or to be using an IDE).

In the future, please add this level of commentary to the PR description before requesting review.

@coolreader18
Copy link
Collaborator Author

Fair enough; I think I figured it was self-explanatory but obviously it wasn't.

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