Implement ranges::unique family

[Michael Schellenberger Costa (miscco)]

This implements ranges::unique and ranges::unique_copy.

Casey Carter (@CaseyCarter): Any good idea on how to test which implementation is actually used? I thought about counting inside the projection if the projected object lies within input or output or somewhere else. But that does not fully work because some of the combinations of the store path trigger the higher ones.

[Michael Schellenberger Costa (miscco)]

For whatever reasons GitHub (@github) does not update the branch. Seems it has trouble

[Stephan T. Lavavej (StephanTLavavej)]

GitHub apparently had some downtime earlier, but I see a code format validation failure because my requested comment edit made the line exceed 120 characters 😹 I think if you fix that, it should pass?

[Michael Schellenberger Costa (miscco)]

I already fixed that and pushed it to github so I do not really know what to do that it picks up the new commit

miscco@89b50da

[Casey Carter (CaseyCarter)]

Casey Carter (@CaseyCarter): Any good idea on how to test which implementation is actually used? I thought about counting inside the projection if the projected object lies within input or output or somewhere else. But that does not fully work because some of the combinations of the store path trigger the higher ones.

I recommend embracing that fact that each of the generator templates is going to generate cases that are handled by each of the three backends in the algorithm. Analyze instantiator::call's template parameters to determine which backend will be used, and then verify that it is.

[Casey Carter (CaseyCarter)]

LGTM after addressing Stephan's comments.

[Michael Schellenberger Costa (miscco)]

hiss at clang

I guess we should limit some of the instantiations here

[Michael Schellenberger Costa (miscco)]

So ranges::unique_copy should be ready to go.

ranges::unique: I got an ICE for you...

[Michael Schellenberger Costa (miscco)]

As far as I can tell the new unwrapping for continuous ranges leads to the ICE.

If i go back to b4fb1f9 and add that lines and the changes to _Seek_to I get the ICE

[Michael Schellenberger Costa (miscco)]

ssiH at reverse

[Casey Carter (CaseyCarter)]

As far as I can tell the new unwrapping for continuous ranges leads to the ICE.

Yes; I applied the if constexpr (!ranges::contiguous_range<ReadWrite>) workaround for VSO-938163 after observing the "all MSVC configs ICE" syndrome. In the unique_copy test, I simplified the projection counting by using the non-key pair member to store the count and split the iterator overload / range overload into separate instantions so TEST_EVERYTHING actually compiles.

[Stephan T. Lavavej (StephanTLavavej)]

Looks good modulo two trivial nitpicks.

[Casey Carter (CaseyCarter)]

Thanks for your, err, one-of-a-kind contribution.