Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

libcore: add Debug implementations to most missing types #32054

Merged
merged 1 commit into from Mar 21, 2016

Conversation

seanmonstar
Copy link
Contributor

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

cc #31869

impl<T: ?Sized + Debug> Debug for UnsafeCell<T> {
fn fmt(&self, f: &mut Formatter) -> Result {
f.debug_struct("UnsafeCell")
.field("value", &unsafe { &*self.get() })
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@bluss
Copy link
Member

bluss commented Mar 5, 2016

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.

@@ -463,7 +463,7 @@ impl<'a, 'b> Pattern<'a> for &'b [char] {
/////////////////////////////////////////////////////////////////////////////

/// Associated type for `<F as Pattern<'a>>::Searcher`.
#[derive(Clone)]
#[derive(Clone, Debug)]
pub struct CharPredicateSearcher<'a, F>(<CharEqPattern<F> as Pattern<'a>>::Searcher)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This one needs a manual impl too.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@seanmonstar
Copy link
Contributor Author

Updated.

@bluss
Copy link
Member

bluss commented Mar 5, 2016

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
Copy link
Member

sfackler commented Mar 5, 2016

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

@seanmonstar
Copy link
Contributor Author

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
Copy link
Member

bluss commented Mar 5, 2016

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
Copy link
Member

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.

@alexcrichton alexcrichton added the T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. label Mar 6, 2016
@bors
Copy link
Contributor

bors commented Mar 6, 2016

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

@bluss
Copy link
Member

bluss commented Mar 6, 2016

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

@seanmonstar
Copy link
Contributor Author

@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 alexcrichton self-assigned this Mar 6, 2016
@alexcrichton
Copy link
Member

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
Copy link
Member

bluss commented Mar 6, 2016

This is not something I made up.

The format docs say

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

@alexcrichton
Copy link
Member

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
Copy link
Contributor Author

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
Copy link
Member

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

@alexcrichton alexcrichton removed the T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. label Mar 17, 2016
@seanmonstar
Copy link
Contributor Author

@alexcrichton rebased and fixed travis tidy complaints.

@alexcrichton
Copy link
Member

@bors: r+ 4ef4b1215ed040b0ddc7f520828555d2e0443fda

Thanks!

@bors
Copy link
Contributor

bors commented Mar 19, 2016

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

@bors
Copy link
Contributor

bors commented Mar 19, 2016

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

@seanmonstar
Copy link
Contributor Author

@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
Copy link
Member

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
Copy link
Contributor Author

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

@alexcrichton
Copy link
Member

@bors: r+ e094593

@bors
Copy link
Contributor

bors commented Mar 21, 2016

⌛ Testing commit e094593 with merge 7ec8f5c...

bors added a commit that referenced this pull request Mar 21, 2016
libcore: add Debug implementations to most missing types

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

cc #31869
@bors bors merged commit e094593 into rust-lang:master Mar 21, 2016
@bluss bluss added the relnotes Marks issues that should be documented in the release notes of the next release. label Mar 21, 2016
@bluss
Copy link
Member

bluss commented Mar 21, 2016

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

bors pushed a commit that referenced this pull request Jul 12, 2016
bors added a commit that referenced this pull request Jul 12, 2016
Derive Debug on FileType.

Partially fixes #32054
d-e-s-o added a commit to d-e-s-o/termion that referenced this pull request Apr 20, 2018
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.
d-e-s-o added a commit to d-e-s-o/termion that referenced this pull request Apr 20, 2018
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.
d-e-s-o added a commit to d-e-s-o/termion that referenced this pull request Apr 21, 2018
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.
d-e-s-o added a commit to d-e-s-o/ssh-agent.rs that referenced this pull request Feb 10, 2019
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.
baloo pushed a commit to baloo/SSH that referenced this pull request Apr 16, 2024
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
relnotes Marks issues that should be documented in the release notes of the next release.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants