Add key and value methods to DebugMap

[KodrAus]

Implementation PR for an active (not approved) RFC: rust-lang/rfcs#2696.

Add two new methods to std::fmt::DebugMap for writing the key and value part of a map entry separately:

impl<'a, 'b: 'a> DebugMap<'a, 'b> {
    pub fn key(&mut self, key: &dyn Debug) -> &mut Self;
    pub fn value(&mut self, value: &dyn Debug) -> &mut Self;
}

I want to do this so that I can write a serde::Serializer that forwards to our format builders, so that any T: Serialize can also be treated like a T: Debug.

[rust-highfive]

Some changes occurred in HTML/CSS.

cc @GuillaumeGomez

[rust-highfive]

r? @rkruppe

(rust_highfive has picked a reviewer for you, use r? to override)

[KodrAus]

Shifting the state of the PadAdapter into a dedicated struct here lets value pick up where key left off without having to guess what the state was before.

[GuillaumeGomez]

@rust-lang/infra: seems like a condition is broken:

Some changes occurred in HTML/CSS.

cc @GuillaumeGomez

[pietroalbini]

Highfive is working as expected though:

https://github.com/rust-lang/highfive/blob/748c035ca2a913cb3bc95404f8665985736f165c/highfive/configs/rust-lang/rust.json#L50-L53

[GuillaumeGomez]

Ah indeed! My bad.

[KodrAus]

Very quick, very dirty benchmark:

#![feature(test)]

extern crate test;

use std::{
    cell::Cell,
    fmt::{self, Write},
};

struct NoOpWrite;

impl Write for NoOpWrite {
    fn write_str(&mut self, _: &str) -> fmt::Result {
        Ok(())
    }
}

#[bench]
fn debugmap_entry(b: &mut test::Bencher) {
    struct Map<'a>(Cell<Option<&'a mut test::Bencher>>);

    impl<'a> fmt::Debug for Map<'a> {
        fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
            let mut map = f.debug_map();

            let b = self.0.take().unwrap();
            b.iter(|| {
                map.entry(&"a", &42);
            });

            map.finish()
        }
    }

    let _ = write!(NoOpWrite, "{:?}", Map(Cell::new(Some(b))));
}

On my machine, running this on the current nightly and this PR yields:

Before	After
36 ns/iter (+/- 7)	44 ns/iter (+/- 2)

So there's a bit of a performance impact like you'd expect, but I don't think it's too significant, and if it is we can inline the implementation in entry.

[KodrAus]

r? @alexcrichton

[alexcrichton]

This all looks great to me! I think this is still waiting on the RFC, though, right?

(FWIW I wouldn't personally consider this as requiring an RFC, but I don't mind waiting if one's open!)

[KodrAus]

Thanks! Yeh, there's an RFC for this at the moment, so I'm also happy to let this sit and wait on that.

[KodrAus]

Alrighty, the RFC has been merged and I've updated the stability attributes to point to the tracking issue.

I think this should be ready to go now!

[alexcrichton]

r=me, thanks!

Looks like CI may be failing though?

[KodrAus]

Looks like we're all good!

@bors r=alexcrichton

[Centril]

@bors r=alexcrichton

[bors]

📌 Commit 70d630f has been approved by alexcrichton

[bors]

⌛ Testing commit 70d630f with merge 909f5a0...