zturner added a subscriber: zturner.
zturner added a comment.
True about the bugnumbers. Not always diferent bug numbers, but certainly
sometimes.
The reason I don't like writing them as separate decorators is because we
have tons of cases where the condition of multiple decorators pass, and the
best we can do is report one bugnumber / reason in the output because we
don't even evaluate the rest after that. If the entire conditional is
specified on one decorator, you can support that.
With functional style you could still support multiple bugnumbers on an or
conditional like this:
@xfail(or(compiler("gcc", [">=", 4.7], bugnumber=12345), hostos("windows",
bugnumber=23456)))
which is equivalent to:
@xfail(compiler="gcc", compiler_version=[">=", 4.7], bugnumber=12345)
@xfail(hostoslist="windows", bugnumber=23456)
I think also having many layers of decorator nesting provides an
implementation challenge. Ultimately we would like to re-use the skipif
functionality of unittest / unittest2 (especially since we want to port to
unittest). So it would be nice if we could write our decorator like this:
def skipIf(...):
def fn(...):
...
unittest2.skipIf(fn)
Right now we can't do this because the nature of the nested decorators
requires us to hack together our own implementation of skipif so that we
can manually call into the next decorator under the right conditions. If
we have just one decorator, it's much easier to write it in terms of
unittest.skipIf. Just construct the function that evaluates the condition,
and pass it in to unittest.
(For what it's worth, I'm not planning to do any of this extra stuff right
now, or even soon, so this is all theoretical at this point. Right now I
just want to remove low hanging fruit and reduce the number of decorators,
but not get it down all the way to 2).
Repository:
rL LLVM
http://reviews.llvm.org/D16936
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
