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]
extern crate std as std;
pub struct Error {
    code: i32,
    msg: &'static str,
}
#[automatically_derived]
#[allow(unused_qualifications)]
impl ::std::fmt::Debug for Error {
    fn fmt(&self, __arg_0: &mut ::std::fmt::Formatter) -> ::std::fmt::Result {
        match *self {
            Error { code: ref __self_0_0, msg: ref __self_0_1 } => {
                let mut builder = __arg_0.debug_struct("Error");
                builder.field("code", &&(*__self_0_0));
                builder.field("msg", &&(*__self_0_1));
                builder.finish()
            }
        }
    }
}

fn main() { }
~ ❯ 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].