The comment was originally added in 4b831a5d.
At that point, it referred only to non-FFP shader constants. Subsequently
38934fe7 moved bumpenv constant loading to the
misc pipeline, apparently out of concerns that bumpenv constants might interact
badly with shader constants.

It's not clear whether those concerns were ever justified, and normal shader
constants are now sufficiently untangled from each other anyway. However,
bumpenv constants, like e.g. color keys, affect both FFP and non-FFP pipelines,
so it makes the most sense for them to remain in the misc state table anyway.

Signed-off-by: Nikolay Sivov <nsivov@codeweavers.com>

Signed-off-by: Nikolay Sivov <nsivov@codeweavers.com>

Signed-off-by: Nikolay Sivov <nsivov@codeweavers.com>

Signed-off-by: Nikolay Sivov <nsivov@codeweavers.com>

push_dc_driver() places drivers based on their priorities, so the newly created driver is not
necessarily on top. Thus in windrv_CreateDC(), find_dc_driver() should be used to find the DIB
driver instead of assuming the DIB driver is the top driver, which could be the path driver because
it has a higher priority.

The exact wrong code path was:
1. A path driver with priority 400 is created for a DC.
2. windrv_CreateDC() is called to create a window driver for the DC.
3. Then in dibdrv_CreateDC(), push_dc_driver() is called with 'dev' pointing to the top driver, which is the path driver.
4. push_dc_driver() updates 'dev' to point to the address of the next driver because DIB driver has a lower 300 priority.
5. The DIB driver is assigned to 'dev', which is not the original parameter passed into push_dc_driver().
6. In windrv_CreateDC(), get_dibdrv_pdev(*dev) is called, assuming the top driver is the DIB driver. But actually the top
   driver that '*dev' points to is still the path driver.

The added tests can demonstrate the memory corruption before this fix is applied.

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=55185

Signed-off-by: Nikolay Sivov <nsivov@codeweavers.com>

LLVM no longer allows non-private labels to appear between
.cfi_startproc/endproc when targeting Mach-O.

Based on a patch by Jacek Caban.

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=55863

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=55920Signed-off-by: Myah Caron <qsniyg@protonmail.com>

In rare cases we get an event during the second iteration of the loop,
changing the first element. This would lead to an assertion later.

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=55054