libcore: add Debug implementations to most missing types by seanmonstar · Pull Request #32054 · rust-lang/rust

seanmonstar · 2016-03-05T02:51:20Z

Also adds #![deny(missing_debug_implementations)] to the core crate.

bluss · 2016-03-05T03:30:01Z

This is unsafe, I don't think UnsafeCell should access its value in Debug.

The unsafety is accessing the inner value to print, when another thread could be writing to it?

We have no idea what the unsafe cell is being used for. Yes, it may need synchronization.

True. It seems that perhaps UnsafeCell shouldn't implement Debug, as it isn't safe. Anyone using an UnsafeCell should manually implement Debug for their own type.

I think it's fine to implement Debug, but it can't show any fields. Printing the ptr value is pointless, since the pointer is just to the interior of the value.

Weak is a precedent, it doesn't show anything about its value either.

bluss · 2016-03-05T03:44:55Z

Nice!

Providing Debug is our policy ("virtually all types should impl Debug") and it's often requested. We will take a compilation time hit from adding a lot of new code to the libraries, but there isn't really a way around it.

bluss · 2016-03-05T03:50:01Z

This one needs a manual impl too.

Oh right, derp. Dealing with F: Fn fields is unfun.

seanmonstar · 2016-03-05T19:22:09Z

Updated.

bluss · 2016-03-05T19:29:18Z

Looks good to me. This is ready to go (r=me by reviewer), but I'd like to wait a day to see if there are any objections.

sfackler · 2016-03-05T19:30:18Z

make tidy is unhappy with the stability attributes: https://travis-ci.org/rust-lang/rust/builds/113934157

seanmonstar · 2016-03-05T20:12:21Z

Hm, so do I invent a new feature, rust1_debug or whatever? Or do I lie and say stable since 1.0.0?

Interestingly, it seems the derived implementations don't have stability markers? They are auto stable? And auto-since-whenever?

bluss · 2016-03-05T20:17:07Z

impls don't have checked stability. You can mark them stable (Debug is stable) with an invented new feature name and since 1.9.0.

alexcrichton · 2016-03-06T07:18:23Z

This is a pretty strong commitment of libcore, so I'm tagging with T-libs to ensure this comes up during triage.

I'm personally pretty uncomfortable with this. I consider all types candidates for Debug but that doesn't mean that we must indeed implement the trait for all types. Most of these will likely never be used, or they're likely not that useful in the first place. To me these end up just adding more bloat to metadata/distribution that isn't necessarily justified.

bors · 2016-03-06T09:18:27Z

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

bluss · 2016-03-06T12:27:11Z

I understand. Not having these though, means that users have more #[derive(Debug)] frustrations.

seanmonstar · 2016-03-06T18:20:45Z

@alexcrichton I understand. My hope is that, if some implementations should be removed, we can mark them as allow, so that we can see the decision was explicit. This way, we can keep deny(missing_debug_implementations), and prevent any accidental omissions on new types that appear. The decision to implement or not should be explicit, not forgotten.

And based on what's decided here, I can go through the other crates and add impls or allow as needed, and in a couple weeks we can be sure no type has been forgotten. Does that sound reasonable?

alexcrichton · 2016-03-06T18:39:27Z

I personally dislike the idea of adding deny(missing_debug_implementations) to a bunch of our crates. Deny-by-default lints in my opinion should have something actionable beyond adding #[allow]. For example right now the standard library denies missing documentation, which arguably helps improve the breadth of documentation in the standard library (and is also easily actionable if it's missing).

I don't think we have much to benefit from exhaustively specifying Debug everywhere, it ends up just being a maintainability hazard and nightmare to keep up to date.

Another worry of mine is that if this is the "best practice" we shouldn't just unilaterally decide that here. We need a more principled way of approaching this as part of the broader Rust ecosystem.

bluss · 2016-03-06T20:10:57Z

This is not something I made up.

The format docs say

fmt::Debug implementations should be implemented for all public types.

alexcrichton · 2016-03-07T07:13:00Z

We can't really cite documentation which is practically ancient and was essentially "defacto stabilized". It's worth reconsidering at least, and in my opinion at the very least rewording the documentation to indicate that it is a candidate for all types, not that it should be implemented for all types.

seanmonstar · 2016-03-07T18:23:20Z

I find many of the objections as subjective, not objective, and I disagree with most of them (surprise!). As long as the libs team looks at them as such, I'm fine with whatever the consensus is.

alexcrichton · 2016-03-17T18:52:11Z

The libs team discussed this yesterday and the decision was to merge. @seanmonstar can you rebase the PR? I'll r+ after!

seanmonstar · 2016-03-18T17:44:51Z

@alexcrichton rebased and fixed travis tidy complaints.

alexcrichton · 2016-03-18T18:23:50Z

@bors: r+ 4ef4b1215ed040b0ddc7f520828555d2e0443fda

Thanks!

bors · 2016-03-19T04:09:27Z

⌛ Testing commit 4ef4b12 with merge 9e2d976...

bors · 2016-03-19T04:11:58Z

💔 Test failed - auto-linux-64-x-freebsd

seanmonstar · 2016-03-19T05:15:10Z

@alexcrichton eek, seems theres a duplicate enum in fmt::mod that is also in fmt::rt::v1. Do I just slap the same derives on it (it's also missing PartialEq from the rt mod), or is this enum strictly for docs, as the commit seems to allude, and thus I should just allow the missing impl?

alexcrichton · 2016-03-19T18:29:09Z

The types in fmt::rt::v1 are internal and probably don't need any trait implementations, the one in fmt is public and likely wants it (it's unstable today though)

seanmonstar · 2016-03-20T18:14:29Z

@alexcrichton ok, I've updated by adding Debug to the public one, and removed Debug from the types in rt::v1.

alexcrichton · 2016-03-21T04:54:29Z

@bors: r+ e094593

bors · 2016-03-21T07:07:33Z

⌛ Testing commit e094593 with merge 7ec8f5c...

libcore: add Debug implementations to most missing types Also adds `#![deny(missing_debug_implementations)]` to the core crate. cc #31869

bors · 2016-03-21T10:21:31Z

☀️ 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-opt-rustbuild, auto-linux-64-x-android-t, auto-linux-64-x-armhf, auto-linux-64-x-armsf, auto-linux-64-x-freebsd, auto-linux-64-x-netbsd, auto-linux-cross-opt, auto-linux-musl-64-opt, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-mac-ios-opt, auto-win-gnu-32-nopt-t, auto-win-gnu-32-opt, auto-win-gnu-32-opt-rustbuild, auto-win-gnu-64-nopt-t, auto-win-gnu-64-opt, auto-win-msvc-32-opt, auto-win-msvc-64-opt, auto-win-msvc-64-opt-rustbuild

bluss · 2016-03-21T11:24:14Z

relnote => a nice improvement for rust users that need #[derive(Debug)]

Partially fixes#32054

Derive Debug on FileType. Partially fixes#32054

It seems to have become common practice for publicly exported types in a library to implement the Debug trait. Doing so potentially simplifies trouble shooting in client code directly but it also is a requirement in case said client code embeds such objects and wants the wrappers to implement this trait. For a deeper discussion of this topic please refer to rust-lang/rust#32054 To that end, this change adjust all publicly exported types to derive from Debug. It also adds a crate wide lint enforcing this constraint.

bluss reviewed Mar 5, 2016
View reviewed changes

seanmonstar force-pushed the impl-debug-core branch from c1284af to 7422dc8Compare March 5, 2016 19:20

alexcrichton added the T-libs-api [DEPRECATED; DO NOT USE] label Mar 6, 2016

alexcrichton self-assigned this Mar 6, 2016

alexcrichton removed the T-libs-api [DEPRECATED; DO NOT USE] label Mar 17, 2016

seanmonstar force-pushed the impl-debug-core branch from 7422dc8 to 4ef4b12Compare March 18, 2016 17:44

libcore: add Debug implementations to most missing types
e094593

seanmonstar force-pushed the impl-debug-core branch from 4ef4b12 to e094593Compare March 20, 2016 17:05

bors added a commit that referenced this pull request Mar 21, 2016
Auto merge of#32054- seanmonstar:impl-debug-core, r=alexcrichton
7ec8f5c
libcore: add Debug implementations to most missing types Also adds `#![deny(missing_debug_implementations)]` to the core crate. cc #31869

bors merged commit e094593 into rust-lang:masterMar 21, 2016

bors mentioned this pull request Mar 21, 2016
resolve: Bind primitive types to items in libcore #32274
Closed

bluss added the relnotes Marks issues that should be documented in the release notes of the next release. label Mar 21, 2016

dimbleby mentioned this pull request May 31, 2016
derive Debug on structures? rust-lang/libc#302
Closed

sourcefrog mentioned this pull request Jul 10, 2016
Derive Debug on FileType. #34757
Merged

bors pushed a commit that referenced this pull request Jul 12, 2016
Derive Debug on FileType.
bba33ec
Partially fixes#32054

bors added a commit that referenced this pull request Jul 12, 2016
Auto merge of#34757- sourcefrog:debug-filetype, r=alexcrichton
3085ec7
Derive Debug on FileType. Partially fixes#32054

hcpl mentioned this pull request Sep 19, 2017
lib: deny missing_debug_implementations mgeisler/textwrap#95
Merged

d-e-s-o mentioned this pull request Apr 20, 2018
Make publicly exported types implement Debug trait redox-os/termion#141
Closed

d-e-s-o mentioned this pull request Feb 10, 2019
Make publicly exported types implement Debug trait sekey/ssh-agent.rs#2
Merged

wprzytula mentioned this pull request Jul 24, 2023
Fix RoutingInfo consistency scylladb/scylla-rust-driver#743
Merged
6 tasks

Uh oh!

Uh oh!

Conversation

seanmonstar commented Mar 5, 2016

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bluss commented Mar 5, 2016

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

seanmonstar commented Mar 5, 2016

Uh oh!

bluss commented Mar 5, 2016

Uh oh!

sfackler commented Mar 5, 2016

Uh oh!

seanmonstar commented Mar 5, 2016

Uh oh!

bluss commented Mar 5, 2016

Uh oh!

alexcrichton commented Mar 6, 2016

Uh oh!

bors commented Mar 6, 2016

Uh oh!

bluss commented Mar 6, 2016

Uh oh!

seanmonstar commented Mar 6, 2016

Uh oh!

alexcrichton commented Mar 6, 2016

Uh oh!

bluss commented Mar 6, 2016

Uh oh!

alexcrichton commented Mar 7, 2016

Uh oh!

seanmonstar commented Mar 7, 2016

Uh oh!

alexcrichton commented Mar 17, 2016

Uh oh!

seanmonstar commented Mar 18, 2016

Uh oh!

alexcrichton commented Mar 18, 2016

Uh oh!

bors commented Mar 19, 2016

Uh oh!

bors commented Mar 19, 2016

Uh oh!

seanmonstar commented Mar 19, 2016

Uh oh!

alexcrichton commented Mar 19, 2016

Uh oh!

seanmonstar commented Mar 20, 2016

Uh oh!

alexcrichton commented Mar 21, 2016

Uh oh!

bors commented Mar 21, 2016

Uh oh!

bors commented Mar 21, 2016

Uh oh!

bluss commented Mar 21, 2016

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!