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