-
Notifications
You must be signed in to change notification settings - Fork 13.6k
Open
Labels
A-lintsArea: Lints (warnings about flaws in source code) such as unused_mut.Area: Lints (warnings about flaws in source code) such as unused_mut.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.
Description
Consider the following code (play):
// Uncomment the `cfg` to see expected output noting `#[warn(unused_must_use)]`
// #[cfg(without_write)]
pub fn encode_json<T: std::fmt::Display>(val: &T, wr: &mut Vec<u8>) {
use std::io::Write;
write!(wr, "{}", val);
}
pub fn after_write_macro() {
Result::Ok::<_, ()>(());
}
fn main() {
}
It generates the following warning:
warning: unused `std::result::Result` which must be used
--> src/main.rs:9:5
|
9 | Result::Ok::<_, ()>(());
| ^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: this `Result` may be an `Err` variant, which should be handled
which is almost, but not quite, what I expect to see.
Namely, I expect to see this:
warning: unused `std::result::Result` which must be used
--> src/main.rs:9:5
|
9 | Result::Ok::<_, ()>(());
| ^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: #[warn(unused_must_use)] on by default
= note: this `Result` may be an `Err` variant, which should be handled
which includes the useful note: #[warn(unused_must_use)] on by default
As far as I can tell, the choice whether or not to include that note is based on the presence/absence of the earlier write!
invocation.
(Hypothesis: perhaps there is an occurrence of an unused must_use within that macros expansion that we are silencing, but even though it is silenced, it is erroneously counted in whatever mechanism we are using to avoid printing out multiple redundant instances of notes like note: #[warn(unused_must_use)] on by default
?)
Metadata
Metadata
Assignees
Labels
A-lintsArea: Lints (warnings about flaws in source code) such as unused_mut.Area: Lints (warnings about flaws in source code) such as unused_mut.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.