Don't chain method calls in #[derive(Debug)]

[sfackler]

Closes#29540

r? @huonw

[huonw]

@bors r+

[bors]

📌 Commit d0bc6a1 has been approved by huonw

[bors]

⌛ Testing commit d0bc6a1 with merge 3c2d6a7...

[bors]

💔 Test failed - auto-mac-64-opt

[alexcrichton]

@bors: retry

On Wed, Nov 4, 2015 at 3:37 AM, bors notifications@github.com wrote:

[image: 💔] Test failed - auto-mac-64-opt
http://buildbot.rust-lang.org/builders/auto-mac-64-opt/builds/6973

—
Reply to this email directly or view it on GitHub
#29565 (comment).

[bors]

⌛ Testing commit d0bc6a1 with merge 9f84cae...

[bors]

💔 Test failed - auto-mac-64-nopt-t

[alexcrichton]

@bors: retry

Hurray git submodules!

This means landing #29546 is not going to be fun.

[bors]

⚡ Previous build results for auto-linux-cross-opt, auto-linux-musl-64-opt, auto-win-msvc-32-opt are reusable. Rebuilding only auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-debug-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-x-android-t, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-win-gnu-32-nopt-t, auto-win-gnu-32-opt, auto-win-gnu-64-nopt-t, auto-win-gnu-64-opt, auto-win-msvc-64-opt...

[bors]

💔 Test failed - auto-linux-32-opt

[alexcrichton]

@bors: retry

On Wed, Nov 4, 2015 at 7:12 PM, bors notifications@github.com wrote:

[image: 💔] Test failed - auto-linux-32-opt
http://buildbot.rust-lang.org/builders/auto-linux-32-opt/builds/7010

—
Reply to this email directly or view it on GitHub
#29565 (comment).

[bors]

⌛ Testing commit d0bc6a1 with merge 3a0409d...

[bors]

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-debug-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-x-android-t, auto-linux-cross-opt, auto-linux-musl-64-opt, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-win-gnu-32-nopt-t, auto-win-gnu-32-opt, auto-win-gnu-64-nopt-t, auto-win-gnu-64-opt, auto-win-msvc-32-opt, auto-win-msvc-64-opt

[alexcrichton]

Hm, I think that this unfortunately caused a regression on nightly, @sfackler do you know off hand what may have caused that?

[sfackler]

@alexcrichton The methods on the builders return a reference to the builder, so if you have #[deny(unused_result)] turned on it'll yell at you:

~ ❯ multirust run nightly rustc test.rs --pretty expanded -Z unstable-options
#![feature(no_std, prelude_import)]#![no_std]#![deny(unused_results)]#[prelude_import]use std::prelude::v1::*;#[macro_use]externcrate std as std;pubstructError{code:i32,msg:&'staticstr,}#[automatically_derived]#[allow(unused_qualifications)]impl::std::fmt::DebugforError{fnfmt(&self,__arg_0:&mut::std::fmt::Formatter) -> ::std::fmt::Result{match*self{Error{code:ref __self_0_0,msg:ref __self_0_1 } => {letmut builder = __arg_0.debug_struct("Error");
builder.field("code",&&(*__self_0_0));
builder.field("msg",&&(*__self_0_1));
builder.finish()}}}}fnmain(){}
~ ❯ multirust run nightly rustc test.rs --pretty expanded -Z unstable-options | multirust run nightly rustc -
<anon>:5:5:5:25 warning: unused import,#[warn(unused_imports)] on by default
<anon>:5 use std::prelude::v1::*;
^~~~~~~~~~~~~~~~~~~~
<anon>:19:17:19:56 error: unused result
<anon>:19 builder.field("code",&&(*__self_0_0));
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<anon>:3:9:3:23 note: lint level defined here
<anon>:3#![deny(unused_results)]
^~~~~~~~~~~~~~
<anon>:20:17:20:55 error: unused result
<anon>:20 builder.field("msg",&&(*__self_0_1));
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<anon>:3:9:3:23 note: lint level defined here
<anon>:3#![deny(unused_results)]
^~~~~~~~~~~~~~
error: aborting due to 2 previous errors

We can fix it by adding some let _ = ...s, but #[deny(unused_result)] seems perhaps excessive?

[alexcrichton]

Oh right, sorry I was mixing up the Result lint and this one! I do agree that this is a little more egregious to fix in that case, but with #29710 cropping up as well I'd perhaps vote to either add an explicit #[allow] or let _ =.

The use case for unused_result at least, making sure results from C libraries aren't dropped on the floor, seems somewhat common at least.

[sfackler]

#[allow] is insufficient since the crate could have a #[forbid].