It's using packaging not distutils. Relates to https://github.com/llvm/llvm-project/issues/54337#issuecomment-2932029662
Despite our attempt (build-docs.sh) to build the documentation with SVG, it still uses PNG https://llvm.org/doxygen/classllvm_1_1StringRef.html, and that renders terribly on any high dpi display. SVG leads to smasller installation and works fine on all browser (that has been true for _a while_ https://caniuse.com/svg), so this patch just unconditionally build all dot graphs as SVG in all subprojects and remove the option.
If `clang-cl.exe` and `lld-link.exe` are installed in `%PATH%`, the Windows release build script will now use these by default, in place of MSVC. The reason for doing this is that MSVC still has, for the past year(s), a O(N^2) behavior when building certain LLVM source files, which leads to long build times (minutes per file). A report was filled here: https://developercommunity.visualstudio.com/t/ON2-in-SparseBitVectorBase-when-com/10657991 Also added a `--force-msvc` option to the script, to use MSVC even if clang-cl is installed.
Since the 19.0 release, the UCRT dlls shouldn't be included anymore in the Windows distribution, as we link the CRT statically into all distributed binaries. https://discourse.llvm.org/t/llvm-x86-64-pc-windows-msvc-binaries-no-longer-need-msvc-runtime-dlls-since-19-x/84465
In #106059 we reduced the targets to those supported by Windows (X86 and ARM) to avoid running into size limitations of the NSIS compiler. Since then, people complained about the lack of Wasm [1], RISC-V [2], BPF [3], and NVPTX [4]. These do seem to fit in the installer (at least for 20.1.0-rc2), so let's add them back. [1] https://discourse.llvm.org/t/llvm-19-x-release-third-party-binaries/80374/26 [2] https://discourse.llvm.org/t/llvm-19-x-release-third-party-binaries/80374/53 [3] https://github.com/llvm/llvm-project/issues/127120 [4] https://github.com/llvm/llvm-project/pull/127794#issuecomment-2668677203
Recently GitHub changed something on their side so we no longer can rebase release PR's with the API. This means that we now have to manually rebase the PR locally and then push the results. This fixes the script that I use to merge PRs to the release branch by changing the rebase part to do the local rebase and also adds a new option --rebase-only so that you can rebase the PRs easier. Minor change is that the script now can take a URL to the pull request as well as just the PR ID.
This reverts commit 9d98acb196a40fee5229afeb08f95fd36d41c10a.
Line ending policies were changed in the parent, dccebddb3b80. To make it easier to resolve downstream merge conflicts after line-ending policies are adjusted this is a separate whitespace-only commit. If you have merge conflicts as a result, you can simply `git add --renormalize -u && git merge --continue` or `git add --renormalize -u && git rebase --continue` - depending on your workflow.
When using bsd sed that ships with macOS on the object files for comparison, every command would error with ``` sed: RE error: illegal byte sequence ``` This was potentially fixed for an older version in 6c52b02e7d0df765da608d8119ae8a20de142cff but even the commands in the example there still have this error. You can repro this with any binary: ``` $ sed s/a/b/ /bin/ls >/dev/null sed: RE error: illegal byte sequence ``` Where LC_CTYPE appears to no longer solve the issue: ``` $ LC_CTYPE=C sed s/a/b/ /bin/ls >/dev/null sed: RE error: illegal byte sequence ``` But this change with LC_ALL does: ``` $ LC_ALL=C sed s/a/b/ /bin/ls >/dev/null; echo $? 0 ``` It seems like the difference here is that if you have LC_ALL set to something else, LC_CTYPE does not override it. More info: https://stackoverflow.com/a/23584470/902968
This was obsoleted by Visual Studio providing built-in support for running clang-format in VS2017. We haven't shipped it for years (since 10d2195305ac49605f2b7b6a25a4076c31923191), never got it working with VS2019, and never even tried with VS2022. It's time to retire the code.