Is, but it is still a lot of typing and we are talking about debuging.
2016-07-27 3:40 GMT-07:00 Manuel Klimek :
> On Wed, Jul 27, 2016 at 1:06 AM Piotr Padlewski via llvm-dev <
> llvm-...@lists.llvm.org> wrote:
>
>> We could also just add nothing() matcher, so debugging would be much
>> easier,
On Wed, Jul 27, 2016 at 1:06 AM Piotr Padlewski via llvm-dev <
llvm-...@lists.llvm.org> wrote:
> We could also just add nothing() matcher, so debugging would be much
> easier, just add anything() or nothing() matcher as extra argument.
>
> The other pros of it is that new developers won't send the
Even if it still did add overhead, it seems perfectly reasonable, from a
user's perspective (namely mine), that if I introduce unnecessary narrowing
matchers to my chain that there may be a performance penalty.
The ability to do the following easily outweighs any performance issues for
me:
anyOf
I was wondering if there is any objection to removing the 2-element minimum
on the eachOf, anyOf and allOf matchers.
It is frustrating when playing with matchers to have to edit significant
amounts of code to be able to temporarily go from 2 to 1 matcher inside an
any- or allOf matcher.
And overa
We could also just add nothing() matcher, so debugging would be much
easier, just add anything() or nothing() matcher as extra argument.
The other pros of it is that new developers won't send the patches that
uses those variadic matchers with only one argument.
2016-07-26 16:02 GMT-07:00 Zac Hans
One of the reasons we added the minimum was because these nodes added
overhead to the matching that was not unnecessary when they only had a
single node.
On the current implementation we could actually get rid of the node
completely for the one argument calls.
I would be ok with removing the lower
