Identical expectation with TIMES causes sequence mismatch

[syyyr]

Hi, since 45ef304414dab7705b99fd7e03f04b837e04e25b, the behavior of this program has changed:

#include <trompeloeil.hpp>

struct MockObject {
    TROMPELOEIL_MAKE_CONST_MOCK1(foo, void(int));
};

int main(void)
{
    MockObject obj;
    trompeloeil::sequence seq;
    REQUIRE_CALL(obj, foo(0)).IN_SEQUENCE(seq).TIMES(1, 666);
    REQUIRE_CALL(obj, foo(0)).IN_SEQUENCE(seq);
    REQUIRE_CALL(obj, foo(1)).IN_SEQUENCE(seq);
    obj.foo(0);
    obj.foo(0);
    obj.foo(1);
}

Before the aforementioned commit, the program would run fine, but after it, it says this:

$ ./a.out 
terminate called after throwing an instance of 'trompeloeil::expectation_violation'
  what():  trompeloeil_bug.cpp:13
Sequence mismatch for sequence "seq" with matching call of obj.foo(1) at trompeloeil_bug.cpp:13. Sequence "seq" has obj.foo(0) at trompeloeil_bug.cpp:11 first in line

Aborted (core dumped)

Is this intentional?

[AndrewPaxie]

I don't know about "intentional" but I will try to reproduce this locally on the main branch and see where this leads.

[rollbear]

It is the way it must be, unless some kind of back tracking is implemented (and since a matching call can have side effects, I don't think backtracking is possible.)

If the second call obj.foo(0) was allowed to match the 2nd expectation, then a third call to obj.foo(0) would fail, since the 2nd expectation would be saturated (i.e., it has reached its maximum allowed number of calls). By staying on the first expectation as long as they are matching, and the upper limit is not reached, the rules become consistent.

Should the documentation be improved to better explain this?

[syyyr]

Hi, sorry for not responding.

Should the documentation be improved to better explain this

Maybe the documentation for TIMES could say that the expectation becomes "greedy" and matches as long as it can. But I'm not sure.

[rollbear]

Finally got around to clarify the docs, and of course found a (pretty obscure) bug in the process. It's fixed on main.

Closing now. Feel free to reopen if you think the docs are not good enough.