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

[Zachary Turner via lldb-commits]

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).

On Tue, Feb 9, 2016 at 10:29 AM Pavel Labath <labath at google.com> wrote:

> On 9 February 2016 at 17:51, Zachary Turner <zturner at google.com> wrote:
> > I agree that you don't need arbitrary complexity, but I think there are
> some things we would greatly benefit from.  For example, have you ever seen
> this?
> >
> >   @expectedFailureWindows
> >   @expectedFailureGcc
> >   @expectedFailureHostLinux
> >
> > That's 3 decorators, when you could write it as 1:
> >
> >   @expectedFailure(or(oslist="windows", compiler="gcc",
> hostoslist="linux"))
>
> Maybe that's a matter of preference, but I would much rather see the
> former than the latter.
>
> What I would like to avoid is having two decorators like:
> @xfail(or(a=A, not(b=B)), c=C')
> @xfail(a=A', or(b=B', not(c=C')))
> on a single test. At that point it becomes quite impossible to figure
> out when the test gets run.
>
> Also, arguably, if you are doing "or", then you are probably dealing
> with separate bugs, and each should deserve it's own bugnumber.
>
> pl
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20160209/17551142/attachment-0001.html>