Revised again: Added TotalEq/TotalOrd/Clone functionality and related tests to B-tree

[niftynif]

Apologies for junking up the feed with all of these separate pull requests. I'm still getting the hang of git and will hopefully be doing less of this nonsense soon. I opened up another PR and closed the one from earlier today because the first PR was coming from the wrong branch of my repo.
Anyway, this contains a fleshed-out implementation of TotalEq/TotalOrd/Clone/ToStr for the whole B-tree structure and relevant tests, integrating suggestions and comments from several community members.
r? @catamorphism

[brson]

Was this intentional? Looks like this might have been an accidental revert.

[brson]

Howdy, @niftynif.

This history is pretty gnarly, with all the merges and seemingly duplicate commits. Can you try to rebase it and squash it into a single commit to make it easier to understand?

I would start by doing a git pull mozilla (replace 'mozilla' with whatever the name you have for the upstream repo is), checking out your branch and doing a rebase mozilla/master, see if that automatically removes some of the duplication. Then rebase mozilla/master -i to do an interactive rebase. Leave the first 'pick' command intact, then replace all the subsequent 'pick's with 's' (for 'squash'). If that succeeds you should end up with a single commit on top of the current master. Then do a force push back to your 'btree' branch with -f; the pull request will automatically update. It will be a bit easier to review that way and the history will be easier to understand.

I haven't looked closely at the logic here since I am that familiar with B-Trees but if nobody else picks it up over the weekend I'll try to take a crack at it after your rebase.

[niftynif]

Hey @brson,
Thanks for the git advice. I've been struggling with git lately and it's good to hear some step-by-step solutions (both from you and @catamorphism). Hopefully in the future I can avoid these problems altogether, but for now, I'll fix it up.

Tim went over the content of the code with me, so we should be set on that front. I have a few suggestions from him to implement in the next day or so, and I plan to get on that as soon as I can. I wrote down a series of revisions to make quickly (many having to do with style).

Thanks again for your help!

[niftynif]

New commits: I opted to keep the [allow(unused_variable)] because it will be taken out once the insertion methods become more than stubs, which will hopefully be on my next PR.

[catamorphism]

Hey @niftynif -- this looks good, but as @brson said, we should really make sure the commit history looks sensible before merging. It's tidier to not have the patch removing the .el file and then the one restoring it at all than to have the two patches in the history, even if the net effect is correct. This should be achievable with git rebase. I'll drop you a line with more details about that, but wanted to make it clear to others that I'm looking at this :-)

[catamorphism]

Hooray! I'm going to review this.

[niftynif]

I'm digging into Bors' logs to see what happened but I'm not really sure what is going on here. Is there anyone who can help me figure it out? I made sure I had a working build before I submitted the PR so I'm a little confused.

[brson]

@niftynif It was a spurious failure, unrelated to your patch. We'll just retry.