let_unit_value triggers on generic return value

[madsmtm]

Summary

When using objc, a library commonly used when dealing with Objective-C, you often have to use let _: () = ... to tell the compiler what the return type, since the return type is generic.

This triggers the lint. Trying to apply the lint's suggestion results in a compilation error. The lint doesn't trigger on Rust 1.61.0.

Lint Name

let_unit_value

Reproducer

I tried the following code (see this playground link for a simplified testcase):

// objc v0.2.7
use objc::{class, msg_send};
use objc::runtime::Object;

let cls = class!(NSObject);
let obj: *mut Object = unsafe { msg_send![cls, new] };
let _: () = unsafe { msg_send![obj, release] };

I expected the lint to not trigger, instead it triggers on the last statement.

Version

rustc 1.63.0-nightly (ec55c6130 2022-06-10)
binary: rustc
commit-hash: ec55c61305eaf385fc1b93ac9a78284b4d887fe5
commit-date: 2022-06-10
host: x86_64-apple-darwin
release: 1.63.0-nightly
LLVM version: 14.0.5

Additional Labels

@rustbot label +regression-from-stable-to-nightly
@rustbot label +I-suggestion-causes-error

[rustbot]

Error: Label regression-from-stable-to-nightly can only be set by Rust team members

Please let @rust-lang/release know if you're having trouble with this bot.

[Jarcho]

I assume the msg_send macro in objc is similar to what you have on the playground. i.e. it doesn't call the function directly, but wraps it in a block of code. Functions returning a generic type should be handled already, but only when the function result is assigned more directly.

[madsmtm]

Yup, that's why I wrote the playground example as such

[Jarcho]

@rustbot claim

[Aaron1011]

For what it's worth, I think that would be a false positive even if the suggestion didn't cause a compilation error. Writing let _: () = some_expr can also be used to assert that an expression produces ().

[lilyball]

I'm running into this with a channel. Approximate code looks like

let (_tx, rx) = oneshot::channel();
let handle = spawn(async {
    let () = rx.await.unwrap();
});

(the context here is a test case for abortion behavior on the spawn function in question, which is why the sender is never used and therefore no other constraints are placed on the channel type)

[booleancoercion]

I don't know why this was marked as closed - as far as I can tell, it was not fixed, at least not in this specific case (in an async context of course):

let () = futures::future::pending().await;