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 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
