[PATCH v2 0/2] MR5324: d3d9/tests: define enums outside of struct

[David Heidelberg (＠dh)]

These two commits shouldn't change anything functional wise, but with minimal changes on wine side, they allow easy integration of d3d9/tests/visual.c into GoogleTest native runner. visual.c code is C++ compatible, except the `enums`.

Second change is done, because we had to redefine `ok()` macro, so without proper braces around conditions it cannot be expanded to multiple lines.

Here is [MR how we import](https://github.com/axeldavy/Xnine/pull/12) the `visual.c`

Third commit just correct my name in the `.mailmap`

My main goal here is bring code which run in Mesa3D CI workflow as closer to the original wine d3d9 tests, so we can easily update from wine and eventually provide also fixes and improvements back.

If you find this MR suitable, we could try figure out a way, to incorporate data about [nine_todo](https://github.com/axeldavy/Xnine/commit/7ac97c8350ea5b2bfd7307ca750ed1d0e51...), of course only if you find some use of these extra information.

/cc @zfigura

--
  v2: mailmap: Add a mailmap entry for myself with the proper name
      d3d9/tests: define enums outside of struct

https://gitlab.winehq.org/wine/wine/-/merge_requests/5324

[PATCH v2 1/2] d3d9/tests: define enums outside of struct

[Pavel Ondračka]

From: Pavel Ondračka

Co-authored-by: David Heidelberg 
Signed-off-by: David Heidelberg 
---
 dlls/d3d9/tests/visual.c | 30 ++++++++++++++++--------------
 1 file changed, 16 insertions(+), 14 deletions(-)

diff --git a/dlls/d3d9/tests/visual.c b/dlls/d3d9/tests/visual.c
index d05649ab92e..36af662f19b 100644
--- a/dlls/d3d9/tests/visual.c
+++ b/dlls/d3d9/tests/visual.c
@@ -1667,16 +1667,17 @@ static void color_fill_test(void)
         {D3DPOOL_MANAGED,    0,                     D3DERR_INVALIDCALL},
         {D3DPOOL_SCRATCH,    0,                     D3DERR_INVALIDCALL},
     };
+    enum format_flags
+    {
+        CHECK_FILL_VALUE = 0x1,
+        BLOCKS           = 0x2,
+        FLOAT_VALUES     = 0x4,
+    };
     static const struct
     {
         D3DFORMAT format;
         const char *name;
-        enum
-        {
-            CHECK_FILL_VALUE = 0x1,
-            BLOCKS           = 0x2,
-            FLOAT_VALUES     = 0x4,
-        } flags;
+        enum format_flags flags;
         unsigned int fill_i[4];
         float fill_f[4];
     }
@@ -23249,16 +23250,17 @@ static void test_texture_blending(void)
         DWORD value;
     };

+    enum texture_stage_texture
+    {
+        TEXTURE_INVALID,
+        TEXTURE_NONE,
+        TEXTURE_BUMPMAP,
+        TEXTURE_RED,
+    };
+
     struct texture_stage
     {
-        enum
-        {
-            TEXTURE_INVALID,
-            TEXTURE_NONE,
-            TEXTURE_BUMPMAP,
-            TEXTURE_RED,
-        }
-        texture;
+        enum texture_stage_texture texture;
         struct texture_stage_state state[20];
     };

[PATCH v2 2/2] mailmap: Add a mailmap entry for myself with the proper name

[David Heidelberg]

From: David Heidelberg

Signed-off-by: David Heidelberg 
---
 .mailmap | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.mailmap b/.mailmap
index 4bd0cee2b2c..7cf13e67174 100644
--- a/.mailmap
+++ b/.mailmap
@@ -18,7 +18,7 @@ Charles Davis 
 Charles Davis 
 Christopher Gautier 
 David A. Cuthbert 
-David Heidelberger 
+David Heidelberg 
 Dennis Björklund 
 Dennis Björklund 
 Dimitrie O. Paun

[Zebediah Figura (＠zfigura)]

> > 2/3
>
> adding the `do {...} while (0)` option could be solution, thou the changes are kinda minimal on wine side without any drawback (if we don't count extra line at the end :wink: ). If you prefer to keep it without braces, I'm ok to drop the commit adjust it on our side.

The diff might be small, but it's not an uncommon construction, and it would be easily broken. And it doesn't seem like it should be that difficult to fix in the GTest integration code.
> > 1/3
>
> Sadly GTest requires the code have at least C++14 and it's very convenient way to integrate it into existing solutions we use (as [deqp-runner](https://gitlab.freedesktop.org/mesa/deqp-runner)).

That's rather unfortunate.
> If it would be inconvenient for wine to carry changes to be compatible with > C++14 in future, we would just patch it by ourselves.

I suppose it depends. Is this the only code incompatible with C++? I'd be mildly surprised if so; are there really no problems with e.g. casting?