Rust 1.81.0 pre-release testing

announcements
1

The 1.81.0 pre-release is ready for testing. The release is scheduled for September 5. 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-09-03/index.html.

The release team is also thinking about changes to our pre-release process: we'd love your feedback on this GitHub issue.

2 Likes
3

Good to see that the warning has made it:

note: this is an inference error on crate time caused by an API change in Rust 1.80.0; update time to version >=0.3.35 by calling cargo update

5 Likes
4

Encountered an annoying instance of the new dependency_on_unit_never_type_fallback lint. Reduction (depends on the nbd crate):

pub fn handle_nbd() -> std::io::Result<()> {
    nbd::server::handshake(std::io::empty(), |_| {
        Ok(nbd::Export {
            ..Default::default()
        })
    })?;
    Ok(())
}

I can add a data: (), to the initializer of nbd::Export to work around this, but this seems awkward and unfortunate. This doesn't seem like something where the never type needed to get involved in the first place.

nbd::Export has a default type parameter of ().

5

Unfortunately​ this is another culprit of defaults not affecting type inference. Constructing nbd::Export::<_> doesn't constrain the Data generic any and leaves it as an unconstrained​ inference variable.

There are certainly times where I wish omitting the generics list meant “use all defaults” instead of “infer all,” but the former has at least as many annoying cases as the latter, if not actually many more.

2 Likes
6

Even with that, where is the ! coming in? I could understand it going "I don't know what type you want, this is underconstrained", but why did it work before while threatening to not work with the fallback change?

7

Exactly because () was used as a fallback type in cases of underconstrained type inference and the lint is warning in cases where that fallback occurs, AIUI.

Although, since choosing ! here would require !: Default, it's at least possible to determine () is the correct choice with a smidge of negative reasoning…

All of the underconstrained type fallback logics end up with weird edge case behaviors, unfortunately​.

2 Likes
8

That would be nice...

9

I suspect it comes from the expansion of ?, the residual type of try trait has ! in it. But I don't have energy to check it now.

10

:confused: Not a fan of regressing 0.6% rustc perf for a lint.

Edit: Ok it got the perf back in the following PR. nvm