Skip to content

use rust 1.68 in rust-toolchain.toml#7891

Closed
gabydd wants to merge 2 commits intohelix-editor:masterfrom
gabydd:1.68-toolchain
Closed

use rust 1.68 in rust-toolchain.toml#7891
gabydd wants to merge 2 commits intohelix-editor:masterfrom
gabydd:1.68-toolchain

Conversation

@gabydd
Copy link
Copy Markdown
Member

@gabydd gabydd commented Aug 9, 2023

fixes the problem found in #7814 (comment) which was an existing problem in helix that could occur while file-walking, this occured due to a bug in rust which was fixed and in included in the 1.68 release. This pr only updates the rust-toolchain.toml so that users building from source won't encounter this bug, but our msrv is still 1.65 which is what we check in CI. As before releases are still built with the latest rust stable so nothing needs to change there.

Copy link
Copy Markdown
Member

@pascalkuthe pascalkuthe left a comment

Choose a reason for hiding this comment

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

It's kind of annoying that we have to use this workaround. Maybe upstream can deal with rust-toolchain.tonl field better in the future.

There are a bunch of closed issues/PRs about automatically detecting the rust version from the rust-toolchain.tonl file but no issues about ignoring/overwriting that file. Perhaps they will be open to that

Regardless thanks for investigating!

@gabydd
Copy link
Copy Markdown
Member Author

gabydd commented Aug 9, 2023

I was looking into that as well we could override the tool chain maybe: https://rust-lang.github.io/rustup/overrides.html

@pascalkuthe
Copy link
Copy Markdown
Member

Yeah an directory overwrite would again have to be done during every CI run so it's not better than just deleting the file temporarily

@pascalkuthe
Copy link
Copy Markdown
Member

Btw. for the release CI' doesn't that also use rustup? I think the rust-toolchain.toml file always takes precedence no matter his we configure CI.

The rust-toolchain workflow works by installing the toolchain and setting the rustup default toolchain. It does nothing soecicial so just like locally the rust-toolchain.toml file always takes priority

@pascalkuthe
Copy link
Copy Markdown
Member

pascalkuthe commented Aug 9, 2023

Ah nvm I mussed that the release CI does the exact same thing as this PR (just with stable jsntead if MSRV). So it's reasonable to do the same here I think

@gabydd
Copy link
Copy Markdown
Member Author

gabydd commented Aug 9, 2023

yeah we remove the rust-toolchain.toml in release, also I think we can set the RUSTUP_TOOLCHAIN environment variable which takes precedence over the rust-toolchain.toml but I guess it's also fine to remove it as well

@pascalkuthe
Copy link
Copy Markdown
Member

The env variabke would be yet another place where we would have to set the MSRV tough. I think J would prefer to just remove the file in CI.

I missed ut before but release CI already does this too :D

@the-mikedavis
Copy link
Copy Markdown
Member

I think we actually want to keep the in-tree rust-toolchain.toml at the MSRV. It's better for local development since check/clippy will catch MSRV violations. It's a rough edge for those cargo installing from source but the bug fixed in 1.68 is an unlikely edge-case to be hit while using Helix normally: I suspect that opening a file picker at / is very rarely done. Anyways we will probably be bumping the MSRV to 1.68 soon enough: the Mozilla docs seem maybe out of date but I believe the ubuntu packages are already caught up to 1.67.

@gabydd gabydd closed this Oct 27, 2023
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