The 1.76.0 pre-release is ready for testing. The release is scheduled for February 8. Release notes can be found here.
You can try it out locally by running:
RUSTUP_DIST_SERVER=https://dev-static.rust-lang.org rustup update stable
The index is https://dev-static.rust-lang.org/dist/2024-02-04/index.html.
The release team is also thinking about changes to our pre-release process: we'd love your feedback on this GitHub issue.
In previous releases, rustup seemed to treat the final-final release as a different version than the version from the pre-release server (obviously I can't check if that's still the case with this one).
i.e. I installed the prerelease 1.75.0 version, and later after the official release date of 1.75.0, I ran rustup update, rustup downloaded 1.75 again, as if it was a different release. That was surprising, because I'd expect the pre-release binaries to be literally the same files that will be released later.
I seem to have some issues with clippy. It reports wrong fixes, and if i force clippy to do those fixes it breaks the code.
It is about the blocks_in_conditions lint.
I did saw some issues, but they also stated resolved. Is this a known issue already?
Updating to the pre-release version with the given command failed for me with:
error: component 'rust-std' for target 'asmjs-unknown-emscripten' is unavailable for download for channel 'stable'
This is obviously caused by "Remove asmjs-unknown-emscripten target" , which is mentioned in the release notes, so the error is expected. However, there is no hint how to solve this issue.
(The correct command to fix it was rustup target remove --toolchain stable-x86_64-unknown-linux-gnu asmjs-unknown-emscripten)
This should still be the case (that's rustup behavior most likely). I would guess it's because the binaries are downloaded from a different place and the manifest describing which binaries are available I, as such, also different.
We're not likely to do a rebuild of artifacts this late in the process for a clippy false positive (and without an available patch to backport). It looks like `await` triggers `blocks_in_conditions` · Issue #12016 · rust-lang/rust-clippy · GitHub is the upstream issue, I'll also flag it on Zulip with the team.
This isn't specific to this release, but it seems like a good idea to file an issue with rustup: Issues · rust-lang/rustup · GitHub to add a suggestion of what to do.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.