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

[Tamas Berghammer via lldb-commits]

tberghammer added a comment.

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

> In http://reviews.llvm.org/D16936#346293, @tberghammer wrote:
>
> > In http://reviews.llvm.org/D16936#346182, @labath wrote:
> >
> > > I agree with the idea in general, but I wanted to ask what is your plan with the android decorators: For them we use the additional `api_levels` flag, which does not exist on other platforms/decorators. I suppose we could add that flag to `expectedFailureAll`, but I am not sure if that would be a good idea...
> > >
> > > Also, since we are doing all this refactoring, one more improvement I can think of is renaming `expectedFailureAll` to `expectedFailure`. It was named `All` because we already have an `expectedFailure` function, but I think that one is now more of an implementation detail and could be renamed to something else. Up to you...
> >
> >
> > My suggestion for the android API level is to add an argument to expectedFailure where you can specify an arbitrary function and then we can write a function called android_device_matches(...) what will return a function checking for the API level. Then this can be used to create very specific xfail conditions what are checking some property of the target system (e.g. "@expectedFailure(fn=hardwareWatchpointsNotSupported)")
>
>
> Yes, that's one option I thought of.   And the function could be specified with any combination of other parameters at the same time, and the result of the function would just be one value checked in determining whether to skip / xfail.


I agree but I also might consider going further where the only thing you can specify is a function and we remove all arguments. Then we implement functions like architectureMatches, targetOsMatches, hostOsMatches, etc.. and some logical function what can combine them (e.g. not, any_of, all_of). This way we just build up the condition in the decorator and we don't have a lot of check inside expectedFailure. What do you think?


http://reviews.llvm.org/D16936