I recently noticed problems with building with clang in msvc mode when using my distro clang. It seems specific to its configuration, I think that it doesn't affect default clang.
One problem is that --rtlib=libgcc is specified in /etc/clang, which causes clang to produce:
```
clang-15: error: unsupported runtime library 'libgcc' for platform 'MSVC'
```
I think it's a clang bug here:
https://github.com/llvm/llvm-project/blob/main/clang/lib/Driver/ToolChains/…
It should probably check for -nodefaultlibs in addition to -nostdlib. It's easy to handle on Wine side by using -nostdlib.
The other problem is that clang for some reason doesn't define `_MSV_VER` by default. I found that it's defined only if I pass `-fuse-ld=lld` to the command line. That's weird because it shouldn't affect compilation step, it should matter only for linking and that's when we pass it. I didn't track it down in clang code itself, but if we can't depend on clang providing it by default, we need to make sure to pass `-fms-compatibility-version` ourselves. The exact version doesn't really matter, we mostly need to make sure that it's defined at all so that our #ifdefs work correctly.
--
v2: configure: Use -fuse-ld=lld also for compilation targets.
winegcc: Use -nostdlib instead of -nostartfiles on Clang MSVC targets.
configure: Use -nostdlib instead of -nostartfiles in WINE_TRY_PE_CFLAGS.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1549
--
v5: mfmediaengine: Add a fallback when the set engine format cannot be used to init samplegrabber.
mfmediaengine: Only accept engine formats which are render target compatible.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1046
Overcooked! All You Can Eat only adds new controllers if existing controller has the same serial as it. SDL GUIDs mark the model of controller, but don't differentiate between multiple controllers of the same model. This is especially bad with Steam virtual controllers, which all have the same GUID.
Switch to using SDL_JoystickGetSerial if available, and otherwise combining the GUID with the controller index
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1551
For the `performance.navigation` props, I store them in the timing that's already linked from the window, to prevent adding more code around that just for 2 props, so it keeps it simple.
--
v3: include/mshtml: Add IHTMLXDomainRequest and factory interfaces and classes.
mshtml: Don't check for doc_node from the doc obj when it can't be NULL.
mshtml: Return proper error for invalid selectors in IE8 mode.
mshtml: Treat edit mode as a reload.
mshtml: Implement performance.navigation.type.
mshtml: Implement performance.navigation.redirectCount.
mshtml: Set `reload` load type to Gecko for document reloads.
mshtml: Implement `onload` prop for input elements.
mshtml: Implement location.reload().
mshtml: Implement print events.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1526
Called by IE11.
Signed-off-by: Mohamad Al-Jaf <mohamadaljaf(a)gmail.com>
v3: Fix failed test.
Don't know how to change the subject version number.
--
v4: shell32/tests: Add SHBindToFolderIDListParent tests.
shell32: Implement SHBindToFolderIDListParent.
shell32: Fix error handling in SHBindToParent.
shell32/tests: Test SHBindToParent last parameter behavior.
https://gitlab.winehq.org/wine/wine/-/merge_requests/566
Fixes an out of bounds access in `show_popup`.
```c
if (menu->FocusedItem != NO_SELECTED_ITEM)
{
menu->items[menu->FocusedItem].fState &= ~(MF_HILITE|MF_MOUSESELECT); // <- can crash here
menu->FocusedItem = NO_SELECTED_ITEM;
}
```
Menu resets focused item on show, not on close.
If items were later deleted, next time user opens the menu, menu can crash on out of bounds access and won't show up again, as menu thinks it's still on screen.
In other words:
- open split button dropdown
- click on any item
- clear dropdown items
- open dropdown again
Menu borked and won't open again.
Source for the testing app for reproduction.
[test.c](/uploads/2f703f63891b33e1a0eb0fcd27c912b7/test.c)
I guess, the alternative is to reset focused item when menu is closed, but not sure where's the best place to do that, haven't dug deep enough.
--
v2: win32u: Reset focused item when removing menu item
win32u: Allow (de)select_item to work with off-screen menus
win32u: Add deselect to HiliteMenuItem
win32u: Return FALSE in HiliteMenuItem when window handle is NULL
https://gitlab.winehq.org/wine/wine/-/merge_requests/1554
If a hlsl_ir_load loads a variable whose components are stored from different
instructions, copy propagation doesn't replace it.
But if all these instructions are constants (which currently is the case
for value constructors), the load can be replaced with a constant value, which
is what the first patch of this series does.
For instance, this shader:
```
sampler s;
Texture2D t;
float4 main() : sv_target
{
return t.Gather(s, float2(0.6, 0.6), int2(0, 0));
}
```
results in the following IR before applying the patch:
```
float | 6.00000024e-01
float | 6.00000024e-01
uint | 0
| = (<constructor-2>[@4].x @2)
uint | 1
| = (<constructor-2>[@6].x @3)
float2 | <constructor-2>
int | 0
int | 0
uint | 0
| = (<constructor-5>[@11].x @9)
uint | 1
| = (<constructor-5>[@13].x @10)
int2 | <constructor-5>
float4 | gather_red(resource = t, sampler = s, coords = @8, offset = @15)
| return
| = (<output-sv_target0> @16)
```
and this IR afterwards:
```
float2 | {6.00000024e-01 6.00000024e-01 }
int2 | {0 0 }
float4 | gather_red(resource = t, sampler = s, coords = @2, offset = @3)
| return
| = (<output-sv_target0> @4)
```
This is required to write texel_offsets as aoffimmi modifiers in the sm4 backend, since it expects the texel_offset arguments to be hlsl_ir_constant.
This series also:
* Allows Gather() methods to use aoffimmi modifiers instead of an additional source register (which is the only way allowed for shader model 4.1), when possible.
* Adds support to texel_offsets in the Load() method via aoffimmi modifiers (the only allowed method).
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/51
Fixes an out of bounds access in `show_popup`.
```c
if (menu->FocusedItem != NO_SELECTED_ITEM)
{
menu->items[menu->FocusedItem].fState &= ~(MF_HILITE|MF_MOUSESELECT); // <- can crash here
menu->FocusedItem = NO_SELECTED_ITEM;
}
```
Menu resets focused item on show, not on close.
If items were later deleted, next time user opens the menu, menu can crash on out of bounds access and won't show up again, as menu thinks it's still on screen.
In other words:
- open split button dropdown
- click on any item
- clear dropdown items
- open dropdown again
Menu borked and won't open again.
Source for the testing app for reproduction.
[test.c](/uploads/2f703f63891b33e1a0eb0fcd27c912b7/test.c)
I guess, the alternative is to reset focused item when menu is closed, but not sure where's the best place to do that, haven't dug deep enough.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1554