[all-commits] [llvm/llvm-project] 0fc578: [lldb][test] Remove expectedFailureIfFn (#81703)

[Jordan Rupprecht via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 0fc578664809d9f808d24a91e50a68d6bfa22118
      https://github.com/llvm/llvm-project/commit/0fc578664809d9f808d24a91e50a68d6bfa22118
  Author: Jordan Rupprecht <rupprecht at google.com>
  Date:   2024-02-14 (Wed, 14 Feb 2024)

  Changed paths:
    M lldb/packages/Python/lldbsuite/test/decorators.py
    M lldb/test/API/commands/platform/sdk/TestPlatformSDK.py
    M lldb/test/API/functionalities/breakpoint/hardware_breakpoints/require_hw_breakpoints/TestRequireHWBreakpoints.py
    M lldb/test/API/functionalities/launch_stop_at_entry/TestStopAtEntry.py

  Log Message:
  -----------
  [lldb][test] Remove expectedFailureIfFn (#81703)

Switching to modern `unittest` in
5b386158aacac4b41126983a5379d36ed413d0ea needs xfail annotations to be
known prior to test running. In contrast, skipping can happen at any
time, even during test execution.

Thus, `expectedFailureIfFn` inherently doesn't work. Either we eagerly
evaluate the function and use `expectedFailureIf` instead, or we use a
skip annotation to lazily evaluate the function and potentially skip the
test right before it starts.

- For `expectedFailureAndroid`, the intent seems to be that certain
tests _should_ work on android, but don't. Thus, xfail is appropriate,
to ensure the test is re-enabled once those bugs are ever fixed.
- For the other uses in individual tests, those generally seem to be
cases where the test environment doesn't support the setup required by
the test, and so it isn't meaningful to run the test at all. For those,
a drop-in replacement to `skipTestIfFn` works.