-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Conversation
impl<T: ?Sized + Debug> Debug for UnsafeCell<T> { | ||
fn fmt(&self, f: &mut Formatter) -> Result { | ||
f.debug_struct("UnsafeCell") | ||
.field("value", &unsafe { &*self.get() }) |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
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) |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
c1284af
to
7422dc8
Compare
Updated. |
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. |
make tidy is unhappy with the stability attributes: https://travis-ci.org/rust-lang/rust/builds/113934157 |
Hm, so do I invent a new feature, Interestingly, it seems the derived implementations don't have stability markers? They are auto stable? And auto-since-whenever? |
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. |
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 |
☔ The latest upstream changes (presumably #30884) made this pull request unmergeable. Please resolve the merge conflicts. |
I understand. Not having these though, means that users have more |
@alexcrichton I understand. My hope is that, if some implementations should be removed, we can mark them as And based on what's decided here, I can go through the other crates and add impls or |
I personally dislike the idea of adding I don't think we have much to benefit from exhaustively specifying 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. |
This is not something I made up. The format docs say
|
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. |
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. |
The libs team discussed this yesterday and the decision was to merge. @seanmonstar can you rebase the PR? I'll r+ after! |
7422dc8
to
4ef4b12
Compare
@alexcrichton rebased and fixed travis tidy complaints. |
@bors: r+ 4ef4b1215ed040b0ddc7f520828555d2e0443fda Thanks! |
⌛ Testing commit 4ef4b12 with merge 9e2d976... |
💔 Test failed - auto-linux-64-x-freebsd |
@alexcrichton eek, seems theres a duplicate enum in |
The types in |
4ef4b12
to
e094593
Compare
@alexcrichton ok, I've updated by adding |
⌛ 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
relnote => a nice improvement for rust users that need #[derive(Debug)] |
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.
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.
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.
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.
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.
Also adds
#![deny(missing_debug_implementations)]
to the core crate.cc #31869