Some fixes to valid clangd warnings, since I am using it as linter.
Also, I am removing enum hlsl_error_level on 4/6, since it doesn't seem to be meant to be used anywhere after 3/6.
--
v3: vkd3d-shader/d3dbc: Use D3DSIO_TEXKILL instead of VKD3D_SM1_OP_TEXKILL (clangd).
vkd3d-shader/hlsl: Remove enum hlsl_error_level (clangd).
vkd3d-shader/tpf: Avoid translations to D3DDECLUSAGE and back (clangd).
vkd3d-shader: Remove unnecessary fallthroughs (clangd).
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/402
The problem with implementing mspatchc for me, is that then tests must be written for that as well :sweat:
Additionally it seems like a bad idea to implement an entire module just to generate data for tests for another module.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3870#note_48550
Check that NULL has no special meaning.
Check GetLastError() for systray windows.
Trace the module filename in case of unexpected success and enclose it
in quotes in case there are leading or trailing spaces.
Fix the filename buffer initialization.
---
The buf2[0] = 0 line at the top of the patch was introduced in
914cb228685b but buf2 was not used after that. So clearly it is buf1
that should have been initialized there.
That said I'm not sure initializing buf1 & buf2 is really necessary as
they are only used in case of success. I guess the fear was that
GetWindowModuleFileName() would sometimes return success without
touching the buffer but I'm not convinced that fear is justified. Still
I decided to be conservative and preserve the initializations. I'm fine
with removing them though (maybe the buf2 case is a bit special).
Finally this is meant to help figure out the reason for the failure
decribed in bug 55777.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4084
- Make it present some frames
- Make it check that the frames are from the new device, instead of checking TerminateDevice count; fixes https://bugs.winehq.org/show_bug.cgi?id=55649
- ~~Make it check for and avoid some absurd crash on Windows~~
~~I tried everything I could think of, but Windows absolutely refuses to present a frame after changing the D3D device, instead choosing to return various absurd errors (segfaults, deadlocks, out of memory, etc). I suspect the VMR9 is haunted.~~
edit: Works on Windows now
--
v4: quartz/tests: Improve VMR9 ChangeD3DDevice test.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3970
Looks like I no longer have the code I used to make test data, but because it generated the minimum amount required to test the features implemented at the time, I think it would not be much help with PE files. Yes, implementing mspatchc may allow proper testing, and it wouldn't need to have especially fast or high-ratio compression, but even then it's not trivial to do. I have my hands full at the moment, but I may look at doing this later if nobody else has.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3870#note_48536