## Summary
Tests for UrlFixupW and semi stub function implementaion.
## Test results
- Tests are 100% ok on my local WIN 10 pc. Wine test bot seems to be okay too.
- Wine tests on debian machine
| function type | result |
| ------ | ------ |
| stub | 0020:url: 69802 tests executed (0 marked as todo, 0 as flaky, **200** failures), 0 skipped. |
| semi stub| 0020:url: 69802 tests executed (0 marked as todo, 0 as flaky, **100** failures), 0 skipped. |
## Todos
For follow up merge request(s).
- [ ] Add more tests for priority investigation, who url scheme fix up is working on windows.
- [ ] Implement missing parts of fix up.
## Conclusion
Semi stub implementation is an improvement to the existing solution. A grep showed that wine internals do not call this function, therefore it should not introduce any new bugs. Windows applications using/relying on the function should now work better, if not they may reveal already existing bugs.
--
v4: shlwapi: fixup leading and trailing typos in UrlFixupW
shlwapi: check for colon in UrlFixupW
kernelbase: Restructure UrlFixupW()
shlwapi/tests: Add tests for UrlFixupW.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1825
On Sun Jan 22 22:25:54 2023 +0000, Thomas Csovcsity wrote:
> Sure, that it can be done. Other parts of the code use goto too. I also
> used already goto in kernel and drivers. ATM i am not able to think
> about a function which would make it easier. If i use early return from
> function, i think it makes no difference, but i plan to use a helper
> function to keep UrlFixup shorter. Any suggestion about the structure is
> well come, because i think i am blind to other and better ways.
It's not cargo-cult avoidance of goto (although in general I think there are only a few situations where it's the most idiomatic choice), but I think using a helper is a lot more readable in patterns like this.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1825#note_21345
On Sun Jan 22 22:25:54 2023 +0000, Thomas Csovcsity wrote:
> source does not have wmemcpy and wcsncpy is defined as:
> `#define wcsncpy(d,s,n) error do_not_use_wcsncpy_use_lstrcpynW_or_memcpy_instead`
In this case you'd write "memcpy(save_str, url_scheme[pos], (len + 1) * sizeof(WCHAR))".
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1825#note_21344
On Sun Dec 18 23:32:22 2022 +0000, Zebediah Figura wrote:
> We use WCHAR, not wchar_t.
> It'd also be nice to use a consistent style for all of variable names in
> this function (wrt snake case vs camel case). In new code I think we
> prefer snake case.
Okay
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1825#note_21342
On Sun Dec 18 23:32:22 2022 +0000, Zebediah Figura wrote:
> Can we use a helper function to fix up the scheme instead of using a
> goto? This will probably also help make the function easier to follow,
> by virtue of being less monolithic.
Sure, that it can be done. Other parts of the code use goto too. I also used already goto in kernel and drivers. ATM i am not able to think about a function which would make it easier. If i use early return from function, i think it makes no difference, but i plan to use a helper function to keep UrlFixup shorter. Any suggestion about the structure is well come, because i think i am blind to other and better ways.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1825#note_21341
On Sun Dec 18 23:28:47 2022 +0000, Zebediah Figura wrote:
> We already know it fits, so this can just be memcpy().
source does not have wmemcpy and wcsncpy is defined as:
`#define wcsncpy(d,s,n) error do_not_use_wcsncpy_use_lstrcpynW_or_memcpy_instead`
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1825#note_21340
On Sun Dec 18 23:24:34 2022 +0000, Zebediah Figura wrote:
> These are constant arrays, so should be "static const WCHAR *const".
> Also, it seems that one array is the same as the other without the final
> colon; can we avoid defining two arrays?
Yes, it is possible to avoid 2 arrays, that is an additional goal. The first goal for me was to avoid additional computation (string manipulation), but i will adjust.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1825#note_21339
First relevant commit:
windows.media.speech: Add a worker thread to the recognition session.
--
v6: windows.media.speech: Store recorded audio in a temporary ringbuffer.
windows.media.speech: Partially implement the speech recognizer state.
windows.media.speech: Add an audio capturing system.
windows.media.speech: Allow the recognition session worker to be paused.
windows.media.speech/tests: Check if stopping the session resets the paused state.
windows.media.speech: Add a worker thread to the recognition session.
windows.media.speech/tests: Test starting, stopping, pausing and resuming the recognition session.
windows.media.speech/tests: Test the recognizer state.
windows.media.speech: Return IAsyncAction from session_PauseAsync.
windows.media.speech: Return IAsyncAction from session_StopAsync.
windows.media.speech: Do not force calling convention on internal callbacks.
windows.media.speech: Move constraints vector to the recognition session.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1948
First relevant commit:
windows.media.speech: Add a worker thread to the recognition session.
--
v5: windows.media.speech: Store recorded audio in a temporary ringbuffer.
windows.media.speech: Partially implement the speech recognizer state.
windows.media.speech: Add an audio capturing system.
windows.media.speech: Allow the recognition session worker to be paused.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1948
Currently it doesn't work as expected, namely gets stuck on delimiter and caret is moved before the delimiter.
Unnecessary more robust than Windows, which feels like doesn't do any checks at all.
EDIT1: v2: return length in `WB_RIGHT` if its bigger than default return value of 0 on invalid values
EDIT2: v3: don't test `WB_ISDELIMITER` with out of bounds indices, Windows doesn't check them and does out of bounds reads
--
v4: comctl32: Fix PathWordBreakProc.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1977
Okay, now the text is correctly written. Please disregard the previous MR I sent by mistake, I already closed it.
*ehem*
I don't expect this MR to be approved (because it is quite big) but I think it would be good if you review it so I start sending it in partitions, and to avoid working on conflicting patches.
But, most importantly, because the patches in the middle of this series contain design decisions pertaining the handling of resource components and register spaces that, I think, are justified by their capability of supporting the many features in the second half of the patch series. Also, in case a different approach is deemed more convenient, it would be good to consider how it would manage the features in these patches.
Most of these design decisions are implemented in the following patches of the series:
```
vkd3d-shader/hlsl: Span variables across multiple register spaces.
vkd3d-shader/hlsl: Support variables that have multiple-registers in object reg. spaces.
```
I converged to these implementations by using Zeb's advice and by hitting myself against the wall while trying to implement these features with other approaches.
In short, this patch series includes:
* For SM1, the tex2D and tex3D intrinsics, inferring generic samplers dimension from usage, writing sampler declarations, and writing sample instructions.
* Support for arrays of resources for both SM1 and SM4 (not to be confused with the resource-arrays of SM 5.1, which can have non-constant indexes).
* Support for declaring resources within structs.
* Support for synthetic combined samplers for SM1 and synthetic separated samplers for SM4, considering that they can be arrays or members of structs.
* All of this while imitating the way the native compiler assigns the register indexes of the resources on allocation, which proved to be the most difficult thing, and the main reason behind the design decisions, because the rules are many, and all the previous things have combined effects in the assignment order.
* (There are also many small fixes to corner cases I have stumbled upon, and validations for cases that should not be supported. Most of them are in short patches and in the first half of the MR).
In order to test that the allocated register indexes (in both the sampler and texture spaces) were the same as the native compiler, I did manual tests using ps_4_0, ps_5_0 and ps_3_0 and compared the CTAB/RDEF sections while trying to deduct the assignment rules. Sadly, I cannot be sure that I am covering 100% of the possible scenarios.
I had to do tests manually since it is difficult to test this with the shader_runner which is also limited to SM4, and I haven't learned how to implement C tests that check the reflection data yet (like the ones in wine that Zeb mentioned test_constant_table() in dlls/d3dcompiler_43/tests/hlsl_d3d9.c). Doing these tests automatically is still missing in this MR.
Nevertheless, I could implement some tests for lowering combined samplers for SM4 that also double down as tests to check for the register assignment order in:
```
tests: Add lowering combined samplers tests.
```
For reference, these are some of the tests I have been running manually both for SM1 and SM4 (with the -GeC flag):
[sm1-separated-samplers.hlsl](/uploads/56019f468f60bd942385c4267dd82754/sm1-separated-samplers.hlsl)
[sm1-separated-samplers-array.hlsl](/uploads/a0d08ae30075db7290f63a91d79eb73c/sm1-separated-samplers-array.hlsl)
[sm1-reserves-and-arrays.hlsl](/uploads/8bcec18556a3981a98b7a206ef2883cf/sm1-reserves-and-arrays.hlsl)
[sm1-reserves-and-dims.hlsl](/uploads/ccbf1b6fe3907354164b8301d179ce5d/sm1-reserves-and-dims.hlsl)
[sm1-separated-samplers-2.hlsl](/uploads/81929a9401bec2050f401a53ec6597e5/sm1-separated-samplers-2.hlsl)
[sm1-separated-and-combined-samplers.hlsl](/uploads/5eb72698df741498bdea262298f88257/sm1-separated-and-combined-samplers.hlsl)
[sm1-combined-order.hlsl](/uploads/6e3e7ee5bacd183ea8d3535ddcb2821c/sm1-combined-order.hlsl)
--
This merge request has too many patches to be relayed via email.
Please visit the URL below to see the contents of the merge request.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/27
copy_propagation_transform_object_load() currently retrieves true, which
indicates that there was progress, even if the input dereference remains
the same.
This can happen repeatedly if an uninitialized object is copied onto
itself, as in the tests added in this patch. This results on the
compilation getting stuck on an endless loop.
This patch checks if the deref didn't change, to retrieve false in that
case.
--
v6: vkd3d-shader/hlsl: Validate that referenced objects are uniform.
tests: Test uninitialized object references.
vkd3d-shader/hlsl: Avoid infinite loop in copy propagation.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/59