[Lldb-commits] [PATCH] D16936: Remove expectedFailureWindows decorator

[Zachary Turner via lldb-commits]

zturner added a comment.

In http://reviews.llvm.org/D16936#346594, @zturner wrote:

> I'm not opposed to it in principle, but I think we should optimize the design for conciseness at the point where you decorate a class or function.  If it makes the point of decoration more verbose or harder to read, then I would probably be against it.  I guess I'd need to see a proposed syntax for what you want it to look like when you decorate a function.


I did think of one possible way to make this elegant (at least in my opinion).  I like the keyword argument syntax because it makes it clear at a glance what you are testing, and it's also very concise while still allowing complex conditionals to be built up.

But one area that is lacking is the ability for it to specify OR conditions.  Basically if you say `@skipIf(A=a, B=b, C=c)` then it only skips if EVERY condition is true.  You hinted at this above, but it would be nice if OR were somehow supported.  So one possibility is something like this:

1. Skips if all conditions are true. @skipIf(all(A=a, B=b, C=c))
2. Skips if any condition is true. @skipIf(any(A=a, B=b, C=c))
3. Skips if none of the conditions are true. @skipIf(none(A=a, B=b, C=c))

Of course, the values here could be `no_match` objects as well, just as now, so you could write:

1. skips if ~a || b || c @skipIf(any(A=no_match(a), B=b, C=c))

but even better, they could be written to take *args and **kwargs as well, so that non-keyword arguments are treated as compound objects.  This is easier to illustrate with an example:

1. skips if ~a || b || c || ~(aa && bb) @skipIf(any(A=no_match(a), B=b, C=c, none(A=aa, B=bb)))

This should support arbitrarily complex conditionals, but is still pretty concise IMO.

Thoughts?


Repository:
  rL LLVM

http://reviews.llvm.org/D16936