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

Add Debug implementations for libcollection structs #39002

Merged
merged 4 commits into from
Feb 7, 2017

Conversation

GuillaumeGomez
Copy link
Member

Part of #31869.

#[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 { .. }")
Copy link
Member

Choose a reason for hiding this comment

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

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.

Copy link
Member Author

Choose a reason for hiding this comment

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

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.

Copy link
Member

Choose a reason for hiding this comment

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

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])

Copy link
Member Author

Choose a reason for hiding this comment

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

I'll add it then.

Copy link
Member Author

Choose a reason for hiding this comment

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

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

Copy link
Member

Choose a reason for hiding this comment

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

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

Copy link
Member Author

Choose a reason for hiding this comment

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

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

Copy link
Member

Choose a reason for hiding this comment

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

/// `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

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

Updated.

@frewsxcv
Copy link
Member

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

@GuillaumeGomez
Copy link
Member Author

I'll add others as well.

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

frewsxcv commented Jan 18, 2017

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

@GuillaumeGomez
Copy link
Member Author

Updated. No more commented impl.

@alexcrichton
Copy link
Member

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

@alexcrichton alexcrichton self-assigned this Jan 19, 2017
@frewsxcv
Copy link
Member

frewsxcv commented Jan 19, 2017

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

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

@alexcrichton
Copy link
Member

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

I removed specialization.

#[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]))
Copy link
Member

Choose a reason for hiding this comment

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

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

#[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))
Copy link
Member

Choose a reason for hiding this comment

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

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

@GuillaumeGomez
Copy link
Member Author

Updated (for the two given).

@GuillaumeGomez
Copy link
Member Author

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

.field(&self.vec.as_slice())
.finish()
}
}
Copy link
Member

Choose a reason for hiding this comment

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

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

Copy link
Member Author

Choose a reason for hiding this comment

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

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. ;)

#[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))
Copy link
Member

Choose a reason for hiding this comment

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

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

Copy link
Member Author

Choose a reason for hiding this comment

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

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

@GuillaumeGomez
Copy link
Member Author

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

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

#[stable(feature = "collection_debug", since = "1.15.0")]
Copy link
Member

Choose a reason for hiding this comment

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

These should all be "1.16.0".

#[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")
Copy link
Member

Choose a reason for hiding this comment

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

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.

Copy link
Member Author

Choose a reason for hiding this comment

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

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

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

#[stable(feature = "collection_debug", since = "1.15.0")]
Copy link
Member

Choose a reason for hiding this comment

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

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

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

#[stable(feature = "collection_debug", since = "1.15.0")]
Copy link
Member

Choose a reason for hiding this comment

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

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

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

#[stable(feature = "collection_debug", since = "1.15.0")]
Copy link
Member

Choose a reason for hiding this comment

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

Again FrontPlace is unstable.

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

#[stable(feature = "collection_debug", since = "1.15.0")]
Copy link
Member

Choose a reason for hiding this comment

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

Again BackPlace is unstable.

@GuillaumeGomez
Copy link
Member Author

@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).

#[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")
Copy link
Member

Choose a reason for hiding this comment

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

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

#[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")
Copy link
Member

Choose a reason for hiding this comment

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

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.

#[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")
Copy link
Member

Choose a reason for hiding this comment

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

This should be a derive

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

Choose a reason for hiding this comment

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

This should be a derive

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)
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 probably infinite recursion

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

Choose a reason for hiding this comment

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

This should be a derive

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

Choose a reason for hiding this comment

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

This should be a derive

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

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

@alexcrichton
Copy link
Member

@rfcbot fcp merge

@rfcbot
Copy link

rfcbot commented Jan 24, 2017

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.

@frewsxcv frewsxcv mentioned this pull request Jan 24, 2017
57 tasks
@alexcrichton
Copy link
Member

ping @sfackler and @brson (checkboxes)

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

#[stable(feature = "collection_debug", since = "1.16.0")]
Copy link
Member

Choose a reason for hiding this comment

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

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

Copy link
Member Author

Choose a reason for hiding this comment

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

Indeed... Updating it.

@GuillaumeGomez
Copy link
Member Author

Updated the release version number to 1.17.

@GuillaumeGomez
Copy link
Member Author

ping @brson

@aturon
Copy link
Member

aturon commented Feb 7, 2017

@bors: r+

@bors
Copy link
Contributor

bors commented Feb 7, 2017

📌 Commit 0cc2448 has been approved by aturon

@bors
Copy link
Contributor

bors commented Feb 7, 2017

⌛ Testing commit 0cc2448 with merge a797b6e...

bors added a commit that referenced this pull request Feb 7, 2017
Add Debug implementations for libcollection structs

Part of #31869.
@bors
Copy link
Contributor

bors commented Feb 7, 2017

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants