Repository navigation
unused_results is stricter on Nightly and Beta than on Stable #44119
Description
This compiles fine on stable, but fails on nightly and beta:
https://play.rust-lang.org/?gist=9504fbb631c253be8e43bcb872524e0e&version=nightly
#![deny(unused_results)]
fn main() {
let mut p = std::path::PathBuf::from("asdf");
p.set_extension("foo");
}Nightly results:
Compiling playground v0.0.1 (file:///playground)
error: unused result
--> src/main.rs:5:4
|
5 | p.set_extension("foo");
| ^^^^^^^^^^^^^^^^^^^^^^^
|
note: lint level defined here
--> src/main.rs:1:9
|
1 | #![deny(unused_results)]
| ^^^^^^^^^^^^^^
error: aborting due to previous error
Regardless of whether the change in behavior is an intentional backward compatibility break, it should be documented in the release notes.
See also #43806.
Activity
zackmdavis commentedon Aug 28, 2017
This is specific to booleans. Not intentional. (I could see a case for the new behavior, but that doesn't matter; if we're going to change this, it should be on purpose.) Fix forthcoming (if it doesn't make the 1.21 beta branch cut, it would need to be backported). Very sorry for regression. 😞 😰 ☠️
un-regress behavior of `unused_results` lint for booleans
eddyb commentedon Aug 28, 2017
FWIW lint changes are not considered backwards-compatibility breaking.
cc @rust-lang/lang
whitequark commentedon Aug 28, 2017
@eddyb Then we should mention that Rust's (or perhaps rustc's?) backwards compatibility guarantee only holds with
--cap-lints warn. It's the default in Cargo for non-root crates, but root crates could still result in breakage on rustc updates if e.g. compiled by scripts.eddyb commentedon Aug 28, 2017
@whitequark Yeah,
--cap-lintsis a relatively new trick and the stability document (I don't even know where to look for it - I think it was an RFC) should be updated if it hasn't been already.briansmith commentedon Aug 28, 2017
@alexcrichton This isn't just a regression from stable to nightly, it is a regression from stable to beta.
OTOH, this is probably the most common lint for which
#[deny(...)]and#[forbid(...)]are used.eddyb commentedon Aug 28, 2017
@briansmith As @whitequark mentioned above, lints can't break dependencies from compiling.
arielb1 commentedon Aug 28, 2017
1.21 is now beta - this needs to be backported.
est31 commentedon Aug 28, 2017
I think this issue is treated wrongly by reverting behaviour (#44122). Rustc needs the ability to add and remove lints in any way wanted, otherwise there won't be any improvement of lints in the future.
E.g. I've seen the "unused_mut" lint become more powerful, it detected some non required mut annotations. Why shouldn't it be possible to improve it? Stability? If you say
#![deny(lint)]you give up that stability guarantee, except if its some very obvious thing likeunsafe.Of course though, @zackmdavis is right, a lint change should be done knowingly and on purpose.
[-]`unused_results` is stricter on Nightly than on Beta or Stable[/-][+]`unused_results` is stricter on Nightly and Beta than on Stable[/+]21 remaining items
Rollup merge of rust-lang#44122 - zackmdavis:booleans_were_not_unused…
alexcrichton commentedon Aug 29, 2017
Nothing like trying to remember a commit from three years ago! Nah unfortunately though I don't remember why
boolwas excepted. Your explanation above though, sounds like the most plausible reason!Yes beta branched a few days ago so this, but with the current disposition to close I don't think we're going to backport/stop anything at this point.
Rollup merge of rust-lang#44122 - zackmdavis:booleans_were_not_unused…
Rollup merge of rust-lang#44122 - zackmdavis:booleans_were_not_unused…
Rollup merge of rust-lang#44122 - zackmdavis:booleans_were_not_unused…
zackmdavis commentedon Aug 29, 2017
@nikomatsakis
Tracking issue is #43302, although I would argue that the currently-unreviewed #44103 (having the lint look at the operators) adequately solves the problem even if it's not the "automatic" implementation folks originally imagined.
rfcbot commentedon Aug 31, 2017
🔔 This is now entering its final comment period, as per the review above. 🔔
rfcbot commentedon Aug 31, 2017
🔔 This is now entering its final comment period, as per the review above. 🔔
rfcbot commentedon Sep 10, 2017
The final comment period is now complete.
Mark-Simulacrum commentedon Sep 12, 2017
Closing, seems we've sufficiently figured this out and no objections were raised.