Implement ranges::remove family

[miscco]

This implements the ranges::remove_{meow} algorithms.

There is something fishy with the copy version that I need to sleep sleep over.

[CaseyCarter]

Just a couple of non-functional nitpicks.

[miscco]

I rebased and squased the previous state and made the changes to the remove_copy{_if} algorithms.

It even compiles locally

[StephanTLavavej]

There appear to be 4 remaining test failures complaining "compiler is out of heap space" although I haven't investigated the root cause.

[miscco]

Yeah I went ahead and implemented the /analyze workaround regarding the ranges::equal comparison

[miscco]

@CaseyCarter I believe we have to limit the number of combinations here or do you have other suggestions on how to prevent the compiler from running out of heap space?

[CaseyCarter]

@CaseyCarter I believe we have to limit the number of combinations here or do you have other suggestions on how to prevent the compiler from running out of heap space?

Poking at the remove_copy test a bit, if I split the range and iterator overload tests into separate classes the /analyze runs succeed even with the assert(ranges::equal back inline - but they are still slow and consume unreasonable memory. I agree that pruning the permutations is the best way forward. (Feel free to poke me in Slack if you'd like to discuss how to best do so.)

[miscco]

I am wondering whether it would be the best to actually prune combinations inside the with_meow_ranges functions so that we uniformly speed up the tests and prevent similar issues like this.

If we would go with some mix with the most requirements this should not affect correctness

[CaseyCarter]

I am wondering whether it would be the best to actually prune combinations inside the with_meow_ranges functions so that we uniformly speed up the tests and prevent similar issues like this.

If we would go with some mix with the most requirements this should not affect correctness

We can't know which properties an algorithm is sensitive to without inspecting its implementation. Conversely, the set of properties to which an algorithm is sensitive could vary under maintenance. If we pick a set of properties a priori and use it for all algorithms we'll invariably miss test coverage. The obviously correct approach - given infinite resources - is to test everything so we know the important properties are covered. This is the rationale for the "generator" functions in range_algorithm_support.hpp being exhaustive.

Of course that also means they are often terrible, and that's ok: we can write algorithm-specific generators that only vary the properties the algorithm observes and put them in the algorithm's test. Colocation also hopefully provides a stronger guarantee that the algorithm and the generator will be maintained together.

[miscco]

@CaseyCarter Given thatthere seems to be some general problem with /analyze I would not trim the tests down and wait for the "fix" to be applied. Hiss if you disagree.

[CaseyCarter]

@CaseyCarter Given that there seems to be some general problem with /analyze I would not trim the tests down and wait for the "fix" to be applied. Hiss if you disagree.

I've updated the problem description in GH-1030 with some more analysis. The /analyze problem seems to only occur for our constexpr testing. I've changed all of our existing workarounds to e.g.:

int main() {
#ifndef _PREFAST_ // TRANSITION, GH-1030
    STATIC_ASSERT((test_in_write<instantiator, int_wrapper, int_wrapper>(), true));
#endif // TRANSITION, GH-1030
    test_in_write<instantiator, int_wrapper, int_wrapper>();
}

(from P0896R4_ranges_alg_move).

[StephanTLavavej]

Approved with nitpick suggestions. Thanks!

[CaseyCarter]

Nice to finally remove this family of algorithms from the todo list ;)