I think this is getting way too complicated. I haven't seen any test which needs such complicated combinations of skip conditions (and I hope I never see one).
On 9 February 2016 at 01:24, Zachary Turner <ztur...@google.com> wrote: > 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)) This is equivalent to: @skipIf(A=a) @skipIf(B=b) @skipIf(C=c) which we already support. > 3. Skips if none of the conditions are true. @skipIf(none(A=a, B=b, C=c)) This can also be written as @skipIf(A=no_match(a), B=no_match(b), ...) I think it is a could idea to keep the skip conditions in some kind of a disjunctive normal form (as they are now), because it makes it clear what the decorator is going to do without having to do mental backflips to figure out the effect. I think the problem here is that you occasionally need to skip based on a strange condition, which cannot be expressed as a combination of existing flags, no matter how many combinators you add (linux distribution name, and android api level are the two that I can think of now), but these can be solved with passing a "function=" argument to @expectedFailureAll. If we see the same kind of a condition function passed to the decorator very often, then we probably need to figure out how to add that as one of the "standard" keyword arguments. pl _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
