Repository navigation
Unused results lint fails on trivial program #43806
Description
The unused_results lint appears to be somewhat overzealous on the current nightly compiler. I managed to reduce the issue down to a simple hello world-program, so something is definitely broken.
I tried this code:
#![deny(unused_results)]
fn main() {
println!("hello world!");
}I expected to see the code compile successfully without any warnings.
Instead, the following error message showed up.
error: unused result
--> src/main.rs:4:5
|
4 | println!("hello world!");
| ^^^^^^^^^^^^^^^^^^^^^^^^^
|
note: lint level defined here
--> src/main.rs:1:9
|
1 | #![deny(unused_results)]
| ^^^^^^^^^^^^^^
= note: this error originates in a macro outside of the current crate
Meta
$ rustc --version
rustc 1.21.0-nightly (13d94d5fa 2017-08-10)
Activity
Mark-Simulacrum commentedon Aug 11, 2017
Bisected to #43728, cc @zackmdavis, @eddyb
kennytm commentedon Aug 11, 2017
Every function call, even those returning
()or!, are considered unused now. 😕pengowen123 commentedon Aug 11, 2017
I would like to work on this if no one else wants to.
zackmdavis commentedon Aug 11, 2017
I see. During #43728, I put the new ununsed-for-functions code after the existing unused-must-use code but before the unused-results check, and modified the unused-must-use code to not return early for types that couldn't be results (including, notably,
()and!), because I wanted to "fall through" to the unused-for-functions code. But()and!shouldn't furthermore "fall through" and be seen as unused results.😰 😢 😞 Sorry, I can submit a fix this afternoon. Thanks for the report, @aepsil0n.
zackmdavis commentedon Aug 11, 2017
@pengowen123 I think I'm morally obligated to do everything in my power to minimize the number of nightlies that are contaminated with my mistake, so I should probably take this unless you're really enthusiastic about fixing it today?
pengowen123 commentedon Aug 11, 2017
@zackmdavis I should be able to fix it today. Don't worry about it being your mistake, I will work on it.
zackmdavis commentedon Aug 11, 2017
@pengowen123 Works for me. I think returning early before the unused-results check if
t.styisty::TyNeveror the empty tuple should suffice? And we'd also want a UI test of the unused_result lint working as expected to make sure this can never happen again.alexcrichton commentedon Aug 12, 2017
This is being fixed in #43813
Auto merge of #43813 - pengowen123:unused_result, r=estebank
pengowen123 commentedon Aug 16, 2017
This is still broken for functions returning structs or non-empty enums. I am working on fixing this.
EDIT: Nevermind, this is intended behavior.
briansmith commentedon Aug 28, 2017
See also #44119. It seems the
unused_resultslint is stricter now, including for example on functions returning boolean results likePathBuf::set_extension().