Stabilize debug builders

[sfackler]

The debug_builders feature is up for 1.1 stabilization in #24028. This commit stabilizes the API as-is with no changes.

Some nits that @alexcrichton mentioned that may be worth discussing now if anyone cares:

• Should debug_tuple_struct and DebugTupleStruct be used instead of debug_tuple and DebugTuple? It's more typing but is a technically more correct name.
• DebugStruct and DebugTuple have field methods while DebugSet, DebugMap and DebugList have entry methods. Should we switch those to something else for consistency?

cc @alexcrichton @aturon

[rust-highfive]

r? @brson

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

[brson]

r? @alexcrichton

[bors]

☔️ The latest upstream changes (presumably #24967) made this pull request unmergeable. Please resolve the merge conflicts.

[alexcrichton]

We got a chance to talk about this today, and the general feeling here is that this stabilization feels a little rushed. I'm curious, but do you know if there's much usage of this feature today? I was personally unaware of many users of this feature or your debug-builders crate.

Overall these APIs also seem like they haven't been subjected to the scrutiny one might expect from a stable API (from the community at large, not necessarily just us per se). In terms of stabilizing new APIs in the standard library we've toyed with the idea of a "final comment period"-like segment of time where users of Rust can browse soon-to-be-stable APIs, but this would take some infrastructure investment to see it realized.

To be clear I don't think the 1.1 window has passed for this feature once we release 1.0, I'm fine cherry picking a change such as this back into beta.

[sfackler]

I'm not aware of a ton of consumers of the API - explicit Debug impls appear to be pretty rare: https://github.com/search?l=rust&p=3&q=%22Debug+for%22&ref=searchresults&type=Code&utf8=%E2%9C%93

Every derived Debug implementation is a consumer, though :)

I think a "final comment period" style thing is a good idea, especially for APIs like this that aren't incredibly heavily used.

[bluss]

I used this API recently, and I wanted a way to display one of my fields in hex. Can we find a simple composable way to do that? I sort of wanted something like this to work: .field("flag", &tag as &fmt::LowerHex).

[sfackler]

The most straightforward way to deal with that right now would be something like

struct DebugHex<T>(T);

impl<T: LowerHex> Debug for DebugHex<T> {
    fn fmt(&self, fmt: &mut Formatter) -> Result {
        self.0.fmt(fmt)
    }
}

...
    .field("flag", &DebugHex(&tag))
...

I'm not sure if there's a way to abstract over Debug, LowerHex etc in a way that would work with your syntax.

[alexcrichton]

@sfackler would you be ok making a post on internals to see if others have comments? (like @bluss!)

[sfackler]

@bluss Actually realized that my original suggestion is both more verbose than it needs to be and not quite right. We don't want to directly forward the Formatter object into LowerHex's fmt method since we wouldn't want to pass along extra formatter flags etc like # since it'll change behavior. A more robust way would be to use format_args! which lets you specify exactly which formatter trait and flags you want to use:

....
    .field("flag", &format_args!("{:x}", self.tag))
....

[bluss]

Excellent, that already works!

[sfackler]

Rebased and shifted to stabilize for 1.2.0 instead of 1.1.0.

[aturon]

@bors: r+

Congrats, and thanks, @sfackler!

[bors]

📌 Commit e161d5c has been approved by aturon

[bors]

⌛️ Testing commit e161d5c with merge 258907d...

[bors]

⛄️ The build was interrupted to prioritize another pull request.

[bors]

⌛️ Testing commit e161d5c with merge 806e61f...

[bors]

💔 Test failed - auto-mac-32-opt

[sfackler]

@bors retry

[bors]

⌛️ Testing commit e161d5c with merge 8bc80ba...

[bors]

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-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

[alexcrichton]

🌴