Add Debug implementations for libcollection structs #39002

GuillaumeGomez · 2017-01-11T22:13:19Z

Part of #31869.

bluss · 2017-01-11T22:45:23Z

src/libcollections/binary_heap.rs

+#[stable(feature = "collection_debug", since = "1.15.0")]
+impl<'a, T: 'a> fmt::Debug for Iter<'a, T> {
+    fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
+        f.pad("BinaryHeap::Iter { .. }")


What's the plan here about showing the elements? It needs specialization to add the case for T: fmt::Debug later, and I don't think we want the complexity of having both impls (without debug bound and with) for each struct.

I kept the implementation as easy as possible. Also, why would it need an implementation for T: fmt::Debug? Except if you want to see the internals, I'm not sure this is very useful.

To identify the iterator with its sequence of elements seems like the logical thing (if it is easy to iterate the sequence from &self). Like how [1, 2, 3].iter() has a debug that shows Iter([1, 2, 3])

I'll add it then.

In this case, it'd require to consume self in order to see the values. I don't think we want this behavior.

Why do you have to consume? Can't you iterate over self.iter.as_slice()?

It doesn't have such a method as far as I can tell, or maybe I missed it?

/// `BinaryHeap` iterator. #[stable(feature = "rust1", since = "1.0.0")] pub struct Iter<'a, T: 'a> { iter: slice::Iter<'a, T>, }

https://doc.rust-lang.org/std/slice/struct.Iter.html#method.as_slice

GuillaumeGomez · 2017-01-16T21:26:16Z

Updated.

frewsxcv · 2017-01-16T22:03:00Z

In my opinion, every impl here should display the Debug for all the items in the collection, not just BinaryHeap::Iter.

GuillaumeGomez · 2017-01-16T22:12:44Z

I'll add others as well.

frewsxcv · 2017-01-18T13:12:58Z

Here's the impl for RangeMut: https://gist.github.com/frewsxcv/5a17ccdbf11ae576ba5c195826fcd0e5

GuillaumeGomez · 2017-01-18T15:10:22Z

Updated. No more commented impl.

alexcrichton · 2017-01-19T01:04:18Z

Why is specialization being used here? Is that being used elsewhere in Debug implementations?

frewsxcv · 2017-01-19T02:10:58Z

Why is specialization being used here? Is that being used elsewhere in Debug implementations?

FWIW, specialization is being used in the other PR you approved: #39156

Also, rg "default fn fmt" does not return any results

GuillaumeGomez · 2017-01-19T10:20:19Z

@alexcrichton: Is it an issue? Sounded like a good idea to me...

alexcrichton · 2017-01-19T20:45:33Z

@GuillaumeGomez yes we don't use specialization for these purposes, just performance in a few minor scenarios. These types should likely all require that generics all implement Debug to stay conservative for now.

GuillaumeGomez · 2017-01-20T12:05:36Z

I removed specialization.

alexcrichton · 2017-01-20T18:48:17Z

src/libcollections/binary_heap.rs

+#[stable(feature = "collection_debug", since = "1.15.0")]
+impl<'a, T: Ord + fmt::Debug> fmt::Debug for PeekMut<'a, T> {
+    fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
+        f.pad(&format!("PeekMut({:?})", self.heap.data[0]))


This should use the debug builders instead of allocating a string.

alexcrichton · 2017-01-20T18:48:44Z

src/libcollections/binary_heap.rs

+#[stable(feature = "collection_debug", since = "1.15.0")]
+impl<'a, T: 'a + fmt::Debug> fmt::Debug for Drain<'a, T> {
+    fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
+        f.pad(&format!("BinaryHeap::Drain({:?})", self.iter))


Same as above with string allocation (and a number of instances below too)

GuillaumeGomez · 2017-01-20T19:59:26Z

Updated (for the two given).

GuillaumeGomez · 2017-01-20T20:52:16Z

A new struct has been added since I started this PR, it has its debug implementation as well.

alexcrichton · 2017-01-20T23:15:33Z

src/libcollections/vec.rs

+         .field(&self.vec.as_slice())
+         .finish()
+    }
+}


How come implementations like this aren't using #{derive(Debug)]?

The habit, didn't thought of testing it, my bad... However, once this PR merged, such cases won't happen again thanks to the corresponding deny option. ;)

alexcrichton · 2017-01-20T23:16:00Z

src/libcollections/btree/set.rs

+#[stable(feature = "collection_debug", since = "1.15.0")]
+impl<T: fmt::Debug> fmt::Debug for IntoIter<T> {
+    fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
+        f.pad(&format!("BTreeSet::IntoIter({:?})", self.iter))


There's still intermediate strings here (and in other places)

Ok, I'll do a pass for the missing ones. Sorry about this.

GuillaumeGomez · 2017-01-20T23:35:31Z

I removed all the format and the PlaceBack struct is now directly deriving Debug. Do you see anything else @alexcrichton?

ollie27 · 2017-01-23T13:12:54Z

src/libcollections/binary_heap.rs

@@ -228,6 +228,15 @@ pub struct PeekMut<'a, T: 'a + Ord> {
    sift: bool,
 }

+#[stable(feature = "collection_debug", since = "1.15.0")]


These should all be "1.16.0".

ollie27 · 2017-01-23T13:17:59Z

src/libcollections/binary_heap.rs

+#[stable(feature = "collection_debug", since = "1.15.0")]
+impl<'a, T: Ord + fmt::Debug> fmt::Debug for PeekMut<'a, T> {
+    fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
+        f.debug_tuple("PeekMut")


To match the others, should this not be "BinaryHeap::PeekMut"? Although it might be better to use part of the actual path like "binary_heap::PeekMut" for all of these instead.

I prefer to refer to the struct used to create the iterator rather than the path of the iterator.

ollie27 · 2017-01-23T13:42:14Z

src/libcollections/binary_heap.rs

@@ -1200,6 +1236,15 @@ where T: Clone + Ord {
    place: vec::PlaceBack<'a, T>,
 }

+#[stable(feature = "collection_debug", since = "1.15.0")]


BinaryHeapPlace is unstable so this impl should get the same stability attribute as BinaryHeapPlace.

ollie27 · 2017-01-23T13:44:27Z

src/libcollections/enum_set.rs

@@ -220,6 +220,15 @@ pub struct Iter<E> {
    marker: marker::PhantomData<E>,
 }

+#[stable(feature = "collection_debug", since = "1.15.0")]


EnumSet is unstable so this stability attribute should probably be removed.

ollie27 · 2017-01-23T13:51:05Z

src/libcollections/linked_list.rs

@@ -1077,6 +1104,15 @@ pub struct FrontPlace<'a, T: 'a> {
    node: IntermediateBox<Node<T>>,
 }

+#[stable(feature = "collection_debug", since = "1.15.0")]


Again FrontPlace is unstable.

ollie27 · 2017-01-23T13:51:19Z

src/libcollections/linked_list.rs

@@ -1121,6 +1157,15 @@ pub struct BackPlace<'a, T: 'a> {
    node: IntermediateBox<Node<T>>,
 }

+#[stable(feature = "collection_debug", since = "1.15.0")]


Again BackPlace is unstable.

GuillaumeGomez · 2017-01-23T16:20:52Z

@ollie27: Thanks for your review! I think I fixed all of them (replacing 1.15 with 1.16 and removing/replacing stable when it was unstable).

alexcrichton · 2017-01-23T17:51:06Z

src/libcollections/binary_heap.rs

+#[stable(feature = "collection_debug", since = "1.16.0")]
+impl<T: fmt::Debug> fmt::Debug for IntoIter<T> {
+    fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
+        f.debug_tuple("BinaryHeap::IntoIter")


Currently the precedence for this is to not have the namespace prefix, so let's remove it.

alexcrichton · 2017-01-23T17:52:19Z

src/libcollections/btree/set.rs

+#[stable(feature = "collection_debug", since = "1.16.0")]
+impl<T: fmt::Debug> fmt::Debug for IntoIter<T> {
+    fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
+        f.debug_tuple("BTreeSet::IntoIter")


This should also just be #[derive]

Note that when I point things out like this it's typically useful to go over the PR looking for other cases as well. I'll try to exhaustively point it out this time but only fixing precisely what is pointed out isn't always the best strategy.

alexcrichton · 2017-01-23T17:52:26Z

src/libcollections/btree/set.rs

+#[stable(feature = "collection_debug", since = "1.16.0")]
+impl<'a, T: 'a + fmt::Debug> fmt::Debug for Range<'a, T> {
+    fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
+        f.debug_tuple("BTreeSet::Range")


This should be a derive

alexcrichton · 2017-01-23T17:53:11Z

src/libcollections/binary_heap.rs

+impl<'a, T: 'a + fmt::Debug> fmt::Debug for Drain<'a, T> {
+    fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
+        f.debug_tuple("BinaryHeap::Drain")
+         .field(&self.iter)


This should be a derive

alexcrichton · 2017-01-23T17:53:22Z

src/libcollections/binary_heap.rs

+impl<'a, T: Clone + Ord + fmt::Debug> fmt::Debug for BinaryHeapPlace<'a, T> {
+    fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
+        f.debug_tuple("BinaryHeapPlace")
+         .field(&self)


This is probably infinite recursion

alexcrichton · 2017-01-23T17:53:34Z

src/libcollections/btree/map.rs

+impl<'a, K: 'a + fmt::Debug, V: 'a + fmt::Debug> fmt::Debug for IterMut<'a, K, V> {
+    fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
+        f.debug_tuple("BTreeMap::IterMut")
+         .field(&self.range)


This should be a derive

alexcrichton · 2017-01-23T17:53:42Z

src/libcollections/btree/map.rs

+impl<'a, K: 'a + fmt::Debug, V: 'a + fmt::Debug> fmt::Debug for ValuesMut<'a, K, V> {
+    fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
+        f.debug_tuple("BTreeMap::ValuesMut")
+         .field(&self.inner)


This should be a derive

GuillaumeGomez · 2017-01-23T21:05:39Z

@alexcrichton: I think I addressed all your review comments.

alexcrichton · 2017-01-24T18:33:06Z

@rfcbot fcp merge

rfcbot · 2017-01-24T18:51:16Z

Team member @alexcrichton has proposed to merge this. The next step is review by the rest of the tagged teams:

No concerns currently listed.

Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

alexcrichton · 2017-02-04T22:09:26Z

ping @sfackler and @brson (checkboxes)

ollie27 · 2017-02-04T23:20:18Z

src/libcollections/binary_heap.rs

@@ -228,6 +228,15 @@ pub struct PeekMut<'a, T: 'a + Ord> {
    sift: bool,
 }

+#[stable(feature = "collection_debug", since = "1.16.0")]


I guess this missed 1.16 so these will need changing to 1.17 now.

Indeed... Updating it.

GuillaumeGomez · 2017-02-05T08:46:44Z

Updated the release version number to 1.17.

GuillaumeGomez · 2017-02-07T10:35:22Z

ping @brson

aturon · 2017-02-07T17:28:43Z

@bors: r+

bors · 2017-02-07T17:28:44Z

📌 Commit 0cc2448 has been approved by aturon

bors · 2017-02-07T17:28:55Z

⌛ Testing commit 0cc2448 with merge a797b6e...

Add Debug implementations for libcollection structs Part of #31869.

bors · 2017-02-07T20:06:53Z

☀️ Test successful - status-appveyor, status-travis
Approved by: aturon
Pushing a797b6e to master...

bluss reviewed Jan 11, 2017

View reviewed changes

alexcrichton added the T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. label Jan 11, 2017

GuillaumeGomez force-pushed the debug_libcollections branch from 9e29d1a to 5b06afd Compare January 16, 2017 21:26

GuillaumeGomez force-pushed the debug_libcollections branch 2 times, most recently from 640d50b to 5dda7f7 Compare January 16, 2017 23:36

GuillaumeGomez force-pushed the debug_libcollections branch from 5dda7f7 to 30691b9 Compare January 18, 2017 15:09

alexcrichton self-assigned this Jan 19, 2017

alexcrichton mentioned this pull request Jan 19, 2017

Add missing Debug implementation for librand structs #39156

Merged

alexcrichton reviewed Jan 20, 2017

View reviewed changes

GuillaumeGomez force-pushed the debug_libcollections branch from 25258cd to 513532e Compare January 20, 2017 19:59

GuillaumeGomez added 3 commits January 20, 2017 21:48

Add Debug implementations for libcollection structs

61fbdbb

Remove Debug implementations specialization

ba841f0

Add debug implementation for BinaryHeapPlace

668af80

GuillaumeGomez force-pushed the debug_libcollections branch from 513532e to 668af80 Compare January 20, 2017 20:51

alexcrichton reviewed Jan 20, 2017

View reviewed changes

ollie27 suggested changes Jan 23, 2017

View reviewed changes

GuillaumeGomez force-pushed the debug_libcollections branch from d62f2b8 to 8daacb3 Compare January 23, 2017 16:19

alexcrichton reviewed Jan 23, 2017

View reviewed changes

GuillaumeGomez force-pushed the debug_libcollections branch 2 times, most recently from b6dd3f1 to 393c3e4 Compare January 23, 2017 21:05

frewsxcv mentioned this pull request Jan 24, 2017

Missing Debug Implementations #31869

Closed

57 tasks

ollie27 reviewed Feb 4, 2017

View reviewed changes

Replace PlaceBack Debug implementation with derive

0cc2448

GuillaumeGomez force-pushed the debug_libcollections branch from 393c3e4 to 0cc2448 Compare February 5, 2017 08:46

bors added a commit that referenced this pull request Feb 7, 2017

Auto merge of #39002 - GuillaumeGomez:debug_libcollections, r=aturon

a797b6e

Add Debug implementations for libcollection structs Part of #31869.

bors merged commit 0cc2448 into rust-lang:master Feb 7, 2017

GuillaumeGomez deleted the debug_libcollections branch February 7, 2017 21:56

sfackler mentioned this pull request Apr 17, 2017

Trying to debug print the difference of two BTreeSets goes into endless print loop. #41338

Closed

jonhoo mentioned this pull request May 11, 2017

Debug impl for HashMap::keys should not require values to be Debug #41924

Closed

Add Debug implementations for libcollection structs #39002

Add Debug implementations for libcollection structs #39002

Conversation

GuillaumeGomez commented Jan 11, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

GuillaumeGomez commented Jan 16, 2017

frewsxcv commented Jan 16, 2017

GuillaumeGomez commented Jan 16, 2017

frewsxcv commented Jan 18, 2017 • edited

GuillaumeGomez commented Jan 18, 2017

alexcrichton commented Jan 19, 2017

frewsxcv commented Jan 19, 2017 • edited

GuillaumeGomez commented Jan 19, 2017

alexcrichton commented Jan 19, 2017

GuillaumeGomez commented Jan 20, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

GuillaumeGomez commented Jan 20, 2017

GuillaumeGomez commented Jan 20, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

GuillaumeGomez commented Jan 20, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

GuillaumeGomez commented Jan 23, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

GuillaumeGomez commented Jan 23, 2017

alexcrichton commented Jan 24, 2017

rfcbot commented Jan 24, 2017 • edited by sfackler

alexcrichton commented Feb 4, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

GuillaumeGomez commented Feb 5, 2017

GuillaumeGomez commented Feb 7, 2017

aturon commented Feb 7, 2017

bors commented Feb 7, 2017

bors commented Feb 7, 2017

bors commented Feb 7, 2017

frewsxcv commented Jan 18, 2017 •

edited

frewsxcv commented Jan 19, 2017 •

edited

rfcbot commented Jan 24, 2017 •

edited by sfackler