Upgrade to Rust 1.86 and bump MSRV to 1.84 #17171

MichaReiser · 2025-04-03T11:44:33Z

Summary

I decided to disable the new needless_continue rule because I often found the explicit continue more readable over an empty block or having to invert the condition of an other branch.

Test Plan

cargo test

github-actions · 2025-04-03T11:46:31Z

`mypy_primer` results

No ecosystem changes detected ✅

github-actions · 2025-04-03T11:55:47Z

`ruff-ecosystem` results

Linter (stable)

✅ ecosystem check detected no linter changes.

Linter (preview)

✅ ecosystem check detected no linter changes.

Formatter (stable)

✅ ecosystem check detected no format changes.

Formatter (preview)

✅ ecosystem check detected no format changes.

crates/red_knot_python_semantic/src/module_resolver/typeshed.rs

crates/ruff/src/args.rs

Co-authored-by: Alex Waygood <[email protected]>

dhruvmanila · 2025-04-03T14:08:08Z

crates/ruff_linter/src/rules/flake8_gettext/rules/printf_in_gettext_func_call.rs

-            op: Operator::Mod { .. },
+            op: Operator::Mod,


Interesting, is this now allowed or was it always allowed and I wasn't aware of it? i.e., matching against an enum struct variant without specifying the fields.

Operator::Mod has no fields. But it seems that Rust still allows you to use { .. } in that case because that also matches "no-fields"

I see and I'm guessing that it's the same for other struct variants for which the { .. } was removed in this PR.

BurntSushi

Nice! Sorry for the late review. I was in the middle of reviewing this when I scratched my cornea, so I figured I'd finish it haha.

BurntSushi · 2025-04-03T18:43:01Z

crates/ruff/src/commands/rule.rs

+        &mut output,
+        "Derived from the **{}** linter.",
+        linter.name()
+    );


I kinda wonder if we should propose add something to std to make this nicer. I like the way the x.push_str(&format!("...")) construction reads much nicer, but I guess this approach avoids an intermediate allocation. But this approach has the very ugly let _ = ...; construction.

That would be great. I definitely don't love it and it has the downside that later refactoring the code to eg use a Write instead of a string now incorrectly suppresses errors (instead of Rust telling you that this might now fail)

* origin/main: [red-knot] Add `Type::TypeVar` variant (#17102) [red-knot] update to latest Salsa with fixpoint caching fix (#17179) Upgrade to Rust 1.86 and bump MSRV to 1.84 (#17171) [red-knot] Avoid unresolved-reference in unreachable code (#17169) Fix relative import resolution in `site-packages` packages when the `site-packages` search path is a subdirectory of the first-party search path (#17178) [DO NOT LAND] bump Salsa version (#17176) [syntax-errors] Detect duplicate keys in `match` mapping patterns (#17129)

## Summary I decided to disable the new [`needless_continue`](https://rust-lang.github.io/rust-clippy/master/index.html#needless_continue) rule because I often found the explicit `continue` more readable over an empty block or having to invert the condition of an other branch. ## Test Plan `cargo test` --------- Co-authored-by: Alex Waygood <[email protected]>

eskultety · 2025-05-07T08:47:58Z

Hello, I'd like to know what the motivation to pin the Rust version to the latest release in rust-toolchain.toml was? Were there any interesting features that this project required to adopt that quickly (literally on the same day of Rust release)?
The reason for my question is that IIUC you're essentially making it impossible for any distro out there to keep up with packaging and everyone is required to rely on rustup to get the exact toolchain version needed to build the project. Before I dive into any further discussion I'd first like to know where my lack of understanding the matter resides and therefore what the real motivation here was/is.

MichaReiser · 2025-05-07T09:11:06Z

Hello, I'd like to know what the motivation to pin the Rust version to the latest release in rust-toolchain.toml was? Were there any interesting features that this project required to adopt that quickly (literally on the same day of Rust release)? The reason for my question is that IIUC you're essentially making it impossible for any distro out there to keep up with packaging and everyone is required to rely on rustup to get the exact toolchain version needed to build the project. Before I dive into any further discussion I'd first like to know where my lack of understanding the matter resides and therefore what the real motivation here was/is.

We're aware that always using the latest version is challenging for downstream packagers. That's why we only use the latest Rust version for local development (and in our release pipelines) but maintain backwards compatibility with latest - 2 as the MSRV with which ruff compiles (see versioning policy). That means Ruff can still be built with Rust 1.84 today.

I think what you're running into is that you clone Ruff's repository and invoke cargo build directly. Cargo then picks up the version specified in rust-toolchain.toml. The version in rust-toolchain.toml is the version we use and using the latest Rust version is desired because it gives us new clippy rules and enables new compiler optimizations in the release artifacts built as part of our pipeline.

I understand is that you want to use a different Rust version. You have a few options:

use rustup override set <version>
Use a toolchain override shorthand cargo +stable
Use the RUSTUP_TOOLCHAIN
Delete the rust-toolchain.toml

You can use any rust version that's compatible with our MSRV (1.84 today). It can be newer or older than the version in our rust-toolchain.toml but it can't be older than the MSRV.

I hope this helps

eskultety · 2025-05-07T09:33:38Z

That's why we only use the latest Rust version for local development (and in our release pipelines)

Hmm, have you considered adopting the latest & greatest primarily in nightly CI builds to get early feedback on new stuff but move the upstream dependency on a slower pace to essentially not "test in production" and by production means all local dev setups? Kinda what Fedora Rawhide is for and commonly consumed in projects' CIs.

I think what you're running into is that you clone Ruff's repository and invoke cargo build directly. Cargo then picks up the version specified in rust-toolchain.toml

Our use case is actually quite different (ties to cargo vendor, not important), but yes, the result is the same. We work in the secure software supply chain field with a strong compliance with the strictest SLSA levels which, among other things, means that builds are network-isolated, hence no rustup updates (also no rustup package). The other major factor (as if network isolation weren't enough :) ) is strict provenance, to put it simply - consuming packages via source tarballs is preferred over binaries.

Use a toolchain override shorthand cargo +stable
Use the RUSTUP_TOOLCHAIN
Delete the rust-toolchain.toml

We may actually consider some of ^this, thanks for the pointer, I admit I didn't pay thorough attention when reading https://rust-lang.github.io/rustup/overrides.html before dropping a comment on this PR. That said, if you say that rust-toolchain.toml is for development and to consume optimizations early for your binary artifacts, would you consider excluding the file from the Python sdist since based on the premise (and based on your backwards compatibility claim) it's irrelevant to have it there for released packages.

MichaReiser · 2025-05-07T09:59:38Z

That said, if you say that rust-toolchain.toml is for development and to consume optimizations early for your binary artifacts, would you consider excluding the file from the Python sdist since based on the premise (and based on your backwards compatibility claim) it's irrelevant to have it there for released packages.

I think that makes sense

MichaReiser · 2025-05-07T10:37:20Z

I created #17909. I'm trying to figure out why we included it in the first place.

Upgrade to Rust 1.86 and bump MSRV to 1.84

c7c8e9f

More clippy

71d6c2a

MichaReiser added the internal An internal refactor or improvement label Apr 3, 2025

MichaReiser marked this pull request as ready for review April 3, 2025 12:45

MichaReiser requested review from carljm, AlexWaygood, sharkdp, dcreager, BurntSushi and dhruvmanila as code owners April 3, 2025 12:45

AlexWaygood approved these changes Apr 3, 2025

View reviewed changes

crates/red_knot_python_semantic/src/module_resolver/typeshed.rs Outdated Show resolved Hide resolved

crates/ruff/src/args.rs Show resolved Hide resolved

Update crates/red_knot_python_semantic/src/module_resolver/typeshed.rs

776e001

Co-authored-by: Alex Waygood <[email protected]>

dhruvmanila approved these changes Apr 3, 2025

View reviewed changes

Merge branch 'main' into micha/rust-1.86

49e4289

MichaReiser enabled auto-merge (squash) April 3, 2025 15:56

MichaReiser merged commit 8a4158c into main Apr 3, 2025
21 checks passed

MichaReiser deleted the micha/rust-1.86 branch April 3, 2025 15:59

BurntSushi reviewed Apr 3, 2025

View reviewed changes

eskultety mentioned this pull request May 7, 2025

Some packages rely on newer Cargo versions than available in UBI9 hermetoproject/hermeto#929

Open

MichaReiser mentioned this pull request May 7, 2025

Exclude rust-toolchain.toml from sdist #17909

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Upgrade to Rust 1.86 and bump MSRV to 1.84 #17171

Upgrade to Rust 1.86 and bump MSRV to 1.84 #17171

Uh oh!

MichaReiser commented Apr 3, 2025 •

edited

Loading

Uh oh!

github-actions bot commented Apr 3, 2025 •

edited

Loading

Uh oh!

github-actions bot commented Apr 3, 2025 •

edited

Loading

Uh oh!

Uh oh!

Uh oh!

dhruvmanila Apr 3, 2025

Uh oh!

MichaReiser Apr 3, 2025

Uh oh!

dhruvmanila Apr 3, 2025

Uh oh!

Uh oh!

BurntSushi left a comment

Uh oh!

BurntSushi Apr 3, 2025

Uh oh!

MichaReiser Apr 3, 2025

Uh oh!

eskultety commented May 7, 2025

Uh oh!

MichaReiser commented May 7, 2025

Uh oh!

eskultety commented May 7, 2025

Uh oh!

MichaReiser commented May 7, 2025

Uh oh!

MichaReiser commented May 7, 2025

Uh oh!

Uh oh!

Upgrade to Rust 1.86 and bump MSRV to 1.84 #17171

Upgrade to Rust 1.86 and bump MSRV to 1.84 #17171

Uh oh!

Conversation

MichaReiser commented Apr 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Test Plan

Uh oh!

github-actions bot commented Apr 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

mypy_primer results

Uh oh!

github-actions bot commented Apr 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

ruff-ecosystem results

Linter (stable)

Linter (preview)

Formatter (stable)

Formatter (preview)

Uh oh!

Uh oh!

Uh oh!

dhruvmanila Apr 3, 2025

Choose a reason for hiding this comment

Uh oh!

MichaReiser Apr 3, 2025

Choose a reason for hiding this comment

Uh oh!

dhruvmanila Apr 3, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

BurntSushi left a comment

Choose a reason for hiding this comment

Uh oh!

BurntSushi Apr 3, 2025

Choose a reason for hiding this comment

Uh oh!

MichaReiser Apr 3, 2025

Choose a reason for hiding this comment

Uh oh!

eskultety commented May 7, 2025

Uh oh!

MichaReiser commented May 7, 2025

Uh oh!

eskultety commented May 7, 2025

Uh oh!

MichaReiser commented May 7, 2025

Uh oh!

MichaReiser commented May 7, 2025

Uh oh!

Uh oh!

MichaReiser commented Apr 3, 2025 •

edited

Loading

github-actions bot commented Apr 3, 2025 •

edited

Loading

`mypy_primer` results

github-actions bot commented Apr 3, 2025 •

edited

Loading

`ruff-ecosystem` results