core::iter::order functions now take two types of iterators.

[TyOverby]

Closes #14278.

Previously the type signatures of the ordering functions in core::iter::order took two iterators, but only if they were the same type of iterator. This commit loosens that restriction and allows different kinds of iterators (but with the same type of elements) to be compared.

[alexcrichton]

Could you add a test that uses two types of iterators as well? It's ok if you don't test all of them.

[huonw]

Looks good! Could you squash the commits please?

(r=me when done)

[pnkfelix]

(i chatted with huon and relayed that I didn't think squashing was strictly required in a scenario like this, i.e. the commits can be considered independently. He was cool with me r+'ing.)

[TyOverby]

Before merging, I want to rename the test that I wrote to not include eq since I changed it to also include testing lt(). I'll squash the commits after fixing this.

[TyOverby]

Can someone explain why these tests passed through travis, but not buildbot? More interesting is that the existing test in the same module that I'm working on should also be failing with the same errors because it also uses .iter() (which according to the compiler error doesn't exist anymore?). Thanks!

[alexcrichton]

Travis does not run a comprehensive test suite, and coretest is not run on travis (the step that failed). You can run the tests yourself with make check-stage0-core.

The failure is likely because libcore doesn't have prelude injection, so the iter() method is not available for slices by default. You'll have to either import prelude::* in the test module, or you'll have to import the relevant trait from the slice module.

[TyOverby]

Oh dang. I was running the Travis tests on my machine thinking they were comprehensive. Thanks for the tip; I'll get this fixed up when I get back tonight!

[TyOverby]

r=huonw