Toolchain+Ports: Update LLVM to 16.0.3#18522
Toolchain+Ports: Update LLVM to 16.0.3#18522awesomekling merged 10 commits intoSerenityOS:masterfrom implicitfield:LLVM
Conversation
|
Hi. Thank you for doing this. We have discussed the situation regarding the libc++ include checks on Discord, would you mind joining the discussion in |
Unfortunately, it looks like Discord won't let me verify my account in a feasible way, so this isn't possible for me at the moment. |
|
Fixing the |
|
Tests are still failing to build, drafting this again for now. |
|
Looks like a bunch of platforms don't actually include a functional |
|
Updated to LLVM 16.0.3, which was released a few days ago. |
| string(REPLACE "../" "" subdirectory "${directory}") | ||
| file(MAKE_DIRECTORY "${CMAKE_STAGING_PREFIX}/${CMAKE_INSTALL_INCLUDEDIR}/${subdirectory}") | ||
| add_custom_command( | ||
| TARGET install_libc_headers |
There was a problem hiding this comment.
if I'm reading this right, this will create a distinct custom command target for each header in LibC? that sounds like... a lot of commands. Is there a way we can do this in one command? I feel like this will be kind of slow.
At the very least, we should make sure that the custom prebuild command has a dependency on the input file location, and that the custom target install_libc_headers has a dependency on the destination file location.
There was a problem hiding this comment.
i.e., have you tested that updating any LibC header will cause this action to re-run?
There was a problem hiding this comment.
Updating any LibC header should indeed cause this to rerun. I believe copy_if_different only works with individual files and directories, so we'd need to move all of LibC's headers into a subdirectory to reduce the amount of commands.
There was a problem hiding this comment.
Right... install(FILES) can work on directories with a FILES_MATCHING pattern, not sure about file(COPY) at configure time or any of the things we can do in the build stage rather than the install or configure stage.
There was a problem hiding this comment.
Install doesn't seem to quite work in this case, since there doesn't seem to be a way to wire it with a custom target, unless I'm missing something? Seems like CMake doesn't support this usecase particularly well.
libc++ disallows including LibC's complex.h in C++ mode. This means that a C++ file cannot expect LibC's complex.h to be included, and thus cannot use c-prefixed complex number functions. As a result, complex.cpp is broken when libc++ has a higher include priority than LibC. A check for __cplusplus has been added to complex.h to warn users of toolchains that don't use libc++.
LibC's complex.h should not be used in C++ code, and libc++'s version implementation does not follow the Serenity C++ style.
This is needed to avoid including LibC headers in Lagom builds.
This is needed to avoid including LibC headers in Lagom builds. Unfortunately, we cannot rely on the build machine to provide a fully POSIX-compatible ELF header for Lagom builds, so we have to use our own.
Once LibC is installed to the sysroot and its conflicts with libc++ are resolved, including LibC headers in such a way will cause errors with a modern LLVM-based toolchain.
Since https://reviews.llvm.org/D131441, libc++ must be included before LibC. As clang includes libc++ as one of the system includes, LibC must be included after those, and the only correct way to do that is to install LibC's headers into the sysroot. Targets that don't link with LibC yet require its headers for one reason or another must add install_libc_headers as a dependency to ensure that the correct headers have been (re)installed into the sysroot. LibC/stddef.h has been dropped since the built-in stddef.h receives a higher include priority. In addition, string.h and wchar.h must define __CORRECT_ISO_CPP_STRING_H_PROTO and _LIBCPP_WCHAR_H_HAS_CONST_OVERLOADS respectively in order to tell libc++ to not try to define methods implemented by LibC.
All uses of this were removed in c4707ed.
This prevents a crash with clang 16.
Last revision before major LLVM bump SerenityOS/serenity#18522
Notes:
IsUnwindTablesDefaultforgetDefaultUnwindTableLeveldue to llvm/llvm-project@4388b56.UnwindTableLevel::Asynchronous, given:serenity/Kernel/CMakeLists.txt
Line 568 in 6990d4e
Meta/CMake/serenity_compile_options.cmakehas been changed to use the new resource location.In addition, the following changes were made to reconcile conflicts between
LibCandlibc++:LibCinto the sysroot, as that's the only way to get the include order right withlibc++.#include <LibC/, as that breaks the new include order.LibC's headers but which don't link againstLibCmust depend oninstall_libc_headersto ensure that those headers have been (re)installed into the sysroot.AK/Complex.his now prohibited, as all of those will point tolibc++when compiling in C++ mode.