Patch Tuesday August 2023.

[BillyONeal]

• Update PowerShell to 7.3.6
• Install ASAN components on Windows.
• Use 1ES to provision Android.
• Update checklist to track removal of manual Linux deployment.
• Fix typo in SAS token minting script.

[BillyONeal]

Failures that don't match: https://dev.azure.com/vcpkg/public/_build/results?buildId=92692&view=logs&j=f79cfdd7-47a8-597f-8f57-dc3e21a8f2ad&t=da63cf11-1f12-503b-6d64-3b2fb713c172

REGRESSION: libxt:x64-windows failed with BUILD_FAILED. If expected, add libxt:x64-windows=fail to C:\a\2\s\scripts\azure-pipelines/../ci.baseline.txt.
REGRESSION: libxt:x64-windows failed with BUILD_FAILED. If expected, add libxt:x64-windows=fail to C:\a\2\s\scripts\azure-pipelines/../ci.baseline.txt.
REGRESSION: libxt:x64-windows failed with BUILD_FAILED. If expected, add libxt:x64-windows=fail to C:\a\2\s\scripts\azure-pipelines/../ci.baseline.txt.
REGRESSION: libxt:x64-windows failed with BUILD_FAILED. If expected, add libxt:x64-windows=fail to C:\a\2\s\scripts\azure-pipelines/../ci.baseline.txt.
REGRESSION: libxt:x64-windows failed with BUILD_FAILED. If expected, add libxt:x64-windows=fail to C:\a\2\s\scripts\azure-pipelines/../ci.baseline.txt.
REGRESSION: openslide:x64-windows failed with BUILD_FAILED. If expected, add openslide:x64-windows=fail to C:\a\2\s\scripts\azure-pipelines/../ci.baseline.txt.

Both of these are not using the right compiler; perhaps they saw asan parts and are trying to pick clang-cl instead. Investigating.

[Neumann-A]

libxt:

.././../src/4f82626eb7-ea5e0a3c95.clean/src/Shell.c(3124,50): error: call to undeclared function '_getpid'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
        snprintf(pid, sizeof(pid), "%ld", (long) getpid());

Looks more like a missing include. libxt needs to use clang-cl due to the use of inline assembly.

Openslide:

D:\buildtrees\openslide\src\v3.4.1-a70eeb2621.clean\test\test-common.c(51,25): error: call to undeclared function '_get_osfhandle'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
  HANDLE hdl = (HANDLE) _get_osfhandle(fd);
                        ^

looks like the same problem. Missing include. Openslide also uses clang-cl due to #switching to clang-cl due to __attribute__((constructor)) in openslide.c

clang-cl is in general more strict about these and will error instead of only warn about those issues.

[BillyONeal]

Looks more like a missing include. libxt needs to use clang-cl due to the use of inline assembly.

That is not OK. The C++ compiler must be the one the triplet says it is. Using clang-cl to compile assembly files is OK but this is clearly not an assembly file.

[Neumann-A]

That is not OK. The C++ compiler must be the one the triplet says it is.

The x64-windows triplet in vcpkg does not explicitly specify a compiler. Also there are always exceptions from implicit rules to make downstream usage possible because otherwise you are basically hard blocking downstream consumers without a very good reason.
If cl does not like to compile the code and clang-cl is the only reasonable way to move forward, clang-cl it is.

[BillyONeal]

https://gitlab.freedesktop.org/xorg/lib/libxt/-/issues/19 submitted upstream

[BillyONeal]

The x64-windows triplet in vcpkg does not explicitly specify a compiler.

It very explicitly specifies a compiler. Which the portfile.cmake is ignoring.

Also there are always exceptions from implicit rules to make downstream usage possible because otherwise you are basically hard blocking downstream consumers without a very good reason.

User said "use this compiler" is that reason. If this thing doesn't support Windows because it can't use the compiler the user said then it can't be in the curated registry. If we merged it, that was in error based on the understanding that it was only used to compile assembly and therefore the C++ compiler the user asked for was still respected.

If cl does not like to compile the code and clang-cl is the only reasonable way to move forward, clang-cl it is.

No. We can/have rejected inclusion in the curated registry on this basis, both because something can't compile with msvc on Windows, or with gcc on Linux.

I'm not going to open the can of worms to try to get rid of this here since that doesn't seem to be the root of the regression (as opposed to the missing headers you point out), but in the future that behavior on the part of ports is unacceptable. The compiler to use is a user setting. Ignoring the user setting is unacceptable.