From 29ebd4a5ff5c0a0eefe802a4bcaa8ef32cc5795a Mon Sep 17 00:00:00 2001
From: Fabian Homborg <FHomborg@gmail.com>
Date: Sat, 13 Mar 2021 17:22:35 +0100
Subject: [PATCH] tests: Don't break when a file unexpectedly exists

Creating a file called "xfoo" could break the highlight tests because
we'd suddenly get a color with valid_path set to true.

So what we do is simply compare foreground/background and forced
underline, but only check for path validity if we're expecting a valid
path.

If we're not expecting a valid path, we don't fail whether it is there
or not.

This means that we can't check for a non-valid path, but we don't
currently do that anyway and we can just burn that bridge when we get
to it.

cc @siteshwar @krobelus, who both came across this
---
 src/fish_tests.cpp | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/src/fish_tests.cpp b/src/fish_tests.cpp
index 5f57f9e64..3f7777138 100644
--- a/src/fish_tests.cpp
+++ b/src/fish_tests.cpp
@@ -5386,7 +5386,16 @@ static void test_highlighting() {
             // Hackish space handling. We don't care about the colors in spaces.
             if (text.at(i) == L' ') continue;
 
-            if (expected_colors.at(i) != colors.at(i)) {
+            auto e = expected_colors.at(i);
+            auto c = colors.at(i);
+            // Compare the colors, but don't care about pathness
+            // unless we're asking for a valid path.
+            //
+            // That way stray files in the build directory don't break the test.
+            if (e.foreground != c.foreground
+                || e.background != c.background
+                || e.force_underline != c.force_underline
+                || (e.valid_path && !c.valid_path)) {
                 const wcstring spaces(i, L' ');
                 err(L"Wrong color in test at index %lu in text (expected %#x, actual "
                     L"%#x):\n%ls\n%ls^",
-- 
2.29.2