llvm-project.git/llvm/lib/Support/Windows/Process.inc, branch users/nico/python-2

[Support] Remove an outdated MinGW workaround (#145294)

2025-06-24T14:13:44+00:00

mingw-w64 has had the _HEAPOK define since the initial commits in 2007;
unclear when/where it was added for mingw.org headers, but it does seem
to exist there as well (at least in versions from 2011).

This workaround stems from 53fbecce6e8b7d1f024e3dc6df4160fe9a577ff1 from
2004 - it is no longer relevant today.

[Support] Silence warnings when retrieving exported functions (#97905)

2024-07-30T23:06:03+00:00

Since functions exported from DLLs are type-erased, before this patch I
was seeing the new Clang 19 warning `-Wcast-function-type-mismatch`.

This happens when building LLVM on Windows.

Following discussion in
https://github.com/llvm/llvm-project/commit/593f708118aef792f434185547f74fedeaf51dd4#commitcomment-143905744

Revert "[Support] Silence function cast warning when building with Clang ToT targetting Windows"

2024-07-06T16:00:41+00:00

This reverts commit 593f708118aef792f434185547f74fedeaf51dd4.

[Support] Silence function cast warning when building with Clang ToT targetting Windows

2024-07-06T00:49:40+00:00

[llvm][Support] Add and use errnoAsErrorCode (#84423)

2024-03-09T07:30:33+00:00

LLVM is inconsistent about how it converts `errno` to `std::error_code`.
This can cause problems because values outside of `std::errc` compare
differently if one is system and one is generic on POSIX systems.

This is even more of a problem on Windows where use of the system
category is just wrong, as that is for Windows errors, which have a
completely different mapping than POSIX/generic errors. This patch fixes
one instance of this mistake in `JSONTransport.cpp`.

This patch adds `errnoAsErrorCode()` which makes it so people do not
need to think about this issue in the future. It also cleans up a lot of
usage of `errno` in LLVM and Clang.

[llvm][Support] Support bright colors in raw_ostream (#80017)

2024-01-31T10:14:02+00:00

[Support] Use StringRef::starts_with/ends_with instead of startswith/endswith. NFC.

2023-11-03T18:19:33+00:00

startswith/endswith wrap starts_with/ends_with and will eventually go away (to more closely match string_view)

[Support] On Windows 11 and Windows Server 2022, fix an affinity mask issue on large core count machines

2023-01-06T22:03:43+00:00

Before Windows 11 and Windows Server 2022, only one 'processor group' is assigned by default to a starting process, then the program is responsible for dispatching its own threads on more 'processor groups'. That is what 8404aeb56a73ab24f9b295111de3b37a37f0b841 was doing, allowing LLVM tools to automatically use all hardware threads in the machine.

After Windows 11 and Windows Server 2022, the OS takes care of that. This has an adverse effect reported in #56618 which is that using `GetProcessAffinityMask()` API in some edge cases seems buggy now. That API is used to detect if an affinity mask was set, and adjust accordingly the available threads for a ThreadPool.

With this patch, on one hand, we let the OS dispatch threads on all 'processor groups', but only for Windows 11 & Windows Server 2022 and after. We retain the old behavior for older OS versions. On the other hand, a workaround was added to mitigate the `GetProcessAffinityMask()` issue described above (see Threading.inc, L226).

Differential Revision: https://reviews.llvm.org/D138747

Process: convert Optional to std::optional

2022-12-06T17:56:14+00:00

This applies to GetEnv and FindInEnvPath.

[llvm] Use std::nullopt instead of llvm::None (NFC)

2022-12-06T07:50:04+00:00

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716