[llvm-branch-commits] [clang] release/19.x: [clang][headers] Including stddef.h always redefines NULL (#99727) (PR #100191)
ian-twilightcoder wrote: > I'm not certain whether the CI failures are related or not. I'm seeing things > like: > > > warning: Linking two modules of different data layouts: > > '/mnt/build/tools/libclc/obj.libclc.dir/cayman-r600--/generic/lib/subnormal_use_default.ll.bc' > > is '' whereas 'llvm-link' is > > 'e-p:32:32-i64:64-v16:16-v24:32-v32:32-v48:64-v96:128-v192:256-v256:256-v512:512-v1024:1024-v2048:2048-n32:64-S32-A5-G1' > > warning: Linking two modules of different data layouts: > > '/mnt/build/tools/libclc/obj.libclc.dir/cayman-r600--/generic/lib/subnormal_helper_func.ll.bc' > > is '' whereas 'llvm-link' is > > 'e-p:32:32-i64:64-v16:16-v24:32-v32:32-v48:64-v96:128-v192:256-v256:256-v512:512-v1024:1024-v2048:2048-n32:64-S32-A5-G1' Those don't _look_ related to NULL. The errors appear to be something wrong with the CMake? ``` 2024-07-23T21:09:14.3963760Z CMake Error at /Users/runner/work/llvm-project/llvm-project/build/lib/cmake/llvm/AddLLVM.cmake:1029 (add_executable): 2024-07-23T21:09:14.3966280Z add_executable cannot create target "prepare_builtins" because an imported 2024-07-23T21:09:14.3968880Z target with the same name already exists. ``` https://github.com/llvm/llvm-project/pull/100191 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [clang] release/19.x: [clang][modules] Enable built-in modules for the upcoming Apple releases (#102239) (PR #102335)
@@ -2923,22 +2923,47 @@ bool Darwin::isAlignedAllocationUnavailable() const {
return TargetVersion < alignedAllocMinVersion(OS);
}
-static bool sdkSupportsBuiltinModules(const Darwin::DarwinPlatformKind
&TargetPlatform, const std::optional &SDKInfo) {
+static bool sdkSupportsBuiltinModules(
+const Darwin::DarwinPlatformKind &TargetPlatform,
+const Darwin::DarwinEnvironmentKind &TargetEnvironment,
+const std::optional &SDKInfo) {
+ switch (TargetEnvironment) {
+ case Darwin::NativeEnvironment:
+ case Darwin::Simulator:
+ case Darwin::MacCatalyst:
+// Standard xnu/Mach/Darwin based environments
+// depend on the SDK version.
+break;
+ default:
ian-twilightcoder wrote:
Should we drop the `default` instead? I guess we could also drop the
TargetEnvironment argument completely since it's not currently needed.
https://github.com/llvm/llvm-project/pull/102335
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [clang] release/19.x: [clang][modules] Enable built-in modules for the upcoming Apple releases (#102239) (PR #102335)
https://github.com/ian-twilightcoder edited https://github.com/llvm/llvm-project/pull/102335 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [clang] release/19.x: [clang][modules] Enable built-in modules for the upcoming Apple releases (#102239) (PR #102335)
https://github.com/ian-twilightcoder deleted https://github.com/llvm/llvm-project/pull/102335 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [clang] release/19.x: [clang][modules] Enable built-in modules for the upcoming Apple releases (#102239) (PR #102517)
https://github.com/ian-twilightcoder created
https://github.com/llvm/llvm-project/pull/102517
Backport 961639962251de7428c3fe93fa17cfa6ab3c561a and
0f1361baf650641a59aaa1710d7a0b7b02f2e56d
Requested by: @ian-twilightcoder
>From 8d764b1ad793d176e943c1c7ad0c979770a81d13 Mon Sep 17 00:00:00 2001
From: Ian Anderson
Date: Wed, 7 Aug 2024 10:14:58 -0700
Subject: [PATCH 1/2] release/19.x: [clang][modules] Enable built-in modules
for the upcoming Apple releases (#102239)
The upcoming Apple SDK releases will support the clang built-in headers
being in the clang built-in modules: stop passing
-fbuiltin-headers-in-system-modules for those SDK versions.
---
clang/lib/Driver/ToolChains/Darwin.cpp| 39 +++
.../Inputs/DriverKit23.0.sdk/SDKSettings.json | 1 +
.../SDKSettings.json | 0
clang/test/Driver/darwin-builtin-modules.c| 5 ++-
4 files changed, 36 insertions(+), 9 deletions(-)
create mode 100644 clang/test/Driver/Inputs/DriverKit23.0.sdk/SDKSettings.json
rename clang/test/Driver/Inputs/{MacOSX99.0.sdk =>
MacOSX15.0.sdk}/SDKSettings.json (100%)
diff --git a/clang/lib/Driver/ToolChains/Darwin.cpp
b/clang/lib/Driver/ToolChains/Darwin.cpp
index c6f9d7beffb1db..b8b2feb5a149e1 100644
--- a/clang/lib/Driver/ToolChains/Darwin.cpp
+++ b/clang/lib/Driver/ToolChains/Darwin.cpp
@@ -2923,22 +2923,47 @@ bool Darwin::isAlignedAllocationUnavailable() const {
return TargetVersion < alignedAllocMinVersion(OS);
}
-static bool sdkSupportsBuiltinModules(const Darwin::DarwinPlatformKind
&TargetPlatform, const std::optional &SDKInfo) {
+static bool sdkSupportsBuiltinModules(
+const Darwin::DarwinPlatformKind &TargetPlatform,
+const Darwin::DarwinEnvironmentKind &TargetEnvironment,
+const std::optional &SDKInfo) {
+ switch (TargetEnvironment) {
+ case Darwin::NativeEnvironment:
+ case Darwin::Simulator:
+ case Darwin::MacCatalyst:
+// Standard xnu/Mach/Darwin based environments
+// depend on the SDK version.
+break;
+ default:
+// All other environments support builtin modules from the start.
+return true;
+ }
+
if (!SDKInfo)
+// If there is no SDK info, assume this is building against a
+// pre-SDK version of macOS (i.e. before Mac OS X 10.4). Those
+// don't support modules anyway, but the headers definitely
+// don't support builtin modules either. It might also be some
+// kind of degenerate build environment, err on the side of
+// the old behavior which is to not use builtin modules.
return false;
VersionTuple SDKVersion = SDKInfo->getVersion();
switch (TargetPlatform) {
+ // Existing SDKs added support for builtin modules in the fall
+ // 2024 major releases.
case Darwin::MacOS:
-return SDKVersion >= VersionTuple(99U);
+return SDKVersion >= VersionTuple(15U);
case Darwin::IPhoneOS:
-return SDKVersion >= VersionTuple(99U);
+return SDKVersion >= VersionTuple(18U);
case Darwin::TvOS:
-return SDKVersion >= VersionTuple(99U);
+return SDKVersion >= VersionTuple(18U);
case Darwin::WatchOS:
-return SDKVersion >= VersionTuple(99U);
+return SDKVersion >= VersionTuple(11U);
case Darwin::XROS:
-return SDKVersion >= VersionTuple(99U);
+return SDKVersion >= VersionTuple(2U);
+
+ // New SDKs support builtin modules from the start.
default:
return true;
}
@@ -3030,7 +3055,7 @@ void Darwin::addClangTargetOptions(
// i.e. when the builtin stdint.h is in the Darwin module too, the cycle
// goes away. Note that -fbuiltin-headers-in-system-modules does nothing
// to fix the same problem with C++ headers, and is generally fragile.
- if (!sdkSupportsBuiltinModules(TargetPlatform, SDKInfo))
+ if (!sdkSupportsBuiltinModules(TargetPlatform, TargetEnvironment, SDKInfo))
CC1Args.push_back("-fbuiltin-headers-in-system-modules");
if (!DriverArgs.hasArgNoClaim(options::OPT_fdefine_target_os_macros,
diff --git a/clang/test/Driver/Inputs/DriverKit23.0.sdk/SDKSettings.json
b/clang/test/Driver/Inputs/DriverKit23.0.sdk/SDKSettings.json
new file mode 100644
index 00..7ba6c244df2115
--- /dev/null
+++ b/clang/test/Driver/Inputs/DriverKit23.0.sdk/SDKSettings.json
@@ -0,0 +1 @@
+{"Version":"23.0", "MaximumDeploymentTarget": "23.0.99"}
diff --git a/clang/test/Driver/Inputs/MacOSX99.0.sdk/SDKSettings.json
b/clang/test/Driver/Inputs/MacOSX15.0.sdk/SDKSettings.json
similarity index 100%
rename from clang/test/Driver/Inputs/MacOSX99.0.sdk/SDKSettings.json
rename to clang/test/Driver/Inputs/MacOSX15.0.sdk/SDKSettings.json
diff --git a/clang/test/Driver/darwin-builtin-modules.c
b/clang/test/Driver/darwin-builtin-modules.c
index 1c56e13bfb9293..ec515133be8aba 100644
--- a/clang/test/Driver/darwin-builtin-modules.c
+++ b/clang/test/Driver/darwin-builtin-modules.c
@@ -6,6 +6,7 @@
// RUN: %clang -isysroot %S/Inputs/iPhoneOS13.0.sdk -target
arm64-apple-ios13.0 -### %s 2>&1 | FileCheck %s
// CHECK: -fbuiltin-headers-in-syste
[llvm-branch-commits] [clang] release/19.x: [clang][modules] Enable built-in modules for the upcoming Apple releases (#102239) (PR #102517)
https://github.com/ian-twilightcoder milestoned https://github.com/llvm/llvm-project/pull/102517 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [clang] release/19.x: [clang][modules] Enable built-in modules for the upcoming Apple releases (#102239) (PR #102335)
https://github.com/ian-twilightcoder closed https://github.com/llvm/llvm-project/pull/102335 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [clang] release/19.x: [clang][modules] Enable built-in modules for the upcoming Apple releases (#102239) (PR #102335)
ian-twilightcoder wrote: Redid as https://github.com/llvm/llvm-project/pull/102517 https://github.com/llvm/llvm-project/pull/102335 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [clang] release/19.x: [clang][modules] Enable built-in modules for the upcoming Apple releases (#102239) (PR #102517)
https://github.com/ian-twilightcoder edited https://github.com/llvm/llvm-project/pull/102517 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [clang] release/19.x: [clang][modules] Enable built-in modules for the upcoming Apple releases (#102239) (PR #102517)
ian-twilightcoder wrote: > I wonder we couldn't amend #102335! Thanks! I couldn't figure out how to add cherry picks onto that PR. I tried another `cherry-pick` in the original PR but the bot just complained. Maybe I could do a single `cherry-pick` command with both commits and that would work? Would that be better than this PR? https://github.com/llvm/llvm-project/pull/102517 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [clang] release/19.x: [clang][modules] Enable built-in modules for the upcoming Apple releases (#102239) (PR #102335)
https://github.com/ian-twilightcoder reopened https://github.com/llvm/llvm-project/pull/102335 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [clang] release/19.x: [clang][modules] Enable built-in modules for the upcoming Apple releases (#102239) (PR #102517)
https://github.com/ian-twilightcoder closed https://github.com/llvm/llvm-project/pull/102517 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [clang] release/19.x: [clang][modules] Enable built-in modules for the upcoming Apple releases (#102239) (PR #102517)
ian-twilightcoder wrote: > > I wonder we couldn't amend #102335! Thanks! > > I couldn't figure out how to add cherry picks onto that PR. I tried another > `cherry-pick` in the original PR but the bot just complained. Maybe I could > do a single `cherry-pick` command with both commits and that would work? > Would that be better than this PR? Ah ha, it worked! Ok let's use #102335 https://github.com/llvm/llvm-project/pull/102517 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [clang] release/19.x: [clang][modules] Enable built-in modules for the upcoming Apple releases (#102239) (PR #102335)
@@ -2923,22 +2923,47 @@ bool Darwin::isAlignedAllocationUnavailable() const {
return TargetVersion < alignedAllocMinVersion(OS);
}
-static bool sdkSupportsBuiltinModules(const Darwin::DarwinPlatformKind
&TargetPlatform, const std::optional &SDKInfo) {
+static bool sdkSupportsBuiltinModules(
+const Darwin::DarwinPlatformKind &TargetPlatform,
+const Darwin::DarwinEnvironmentKind &TargetEnvironment,
+const std::optional &SDKInfo) {
+ switch (TargetEnvironment) {
+ case Darwin::NativeEnvironment:
+ case Darwin::Simulator:
+ case Darwin::MacCatalyst:
+// Standard xnu/Mach/Darwin based environments
+// depend on the SDK version.
+break;
+ default:
ian-twilightcoder wrote:
Added that commit
https://github.com/llvm/llvm-project/pull/102335
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [clang] release/18.x: [clang][modules] giving the __stddef_ headers their own modules can cause redeclaration errors with -fbuiltin-headers-in-system-modules (#84127) (PR #85118)
ian-twilightcoder wrote: @tstellar can you merge this one for me please? https://github.com/llvm/llvm-project/pull/85118 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [libcxx] release/18.x: [libc++] Simplify the implementation of (#86843) (PR #87374)
ian-twilightcoder wrote: @tstellar what do you think? I'm a little nervous someone else will run into mysterious errors where `rsize_t` isn't declared in C++ mode, and if they aren't intimately familiar with the workings of the clang header they're going to be very confused for a very long time. But on the other hand no one else has run into that yet as far as we know, and stddef.h _is_ particularly touchy. I would err on the side of taking this, at it effectively fixes a C++ regression caused by https://reviews.llvm.org/D157757 https://github.com/llvm/llvm-project/pull/87374 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [clang] release/18.x: [Headers] Don't declare unreachable() from stddef.h in C++ (#86748) (PR #87696)
ian-twilightcoder wrote: Nominating for backport because this is a C++ regression that was caused by https://reviews.llvm.org/D157757 https://github.com/llvm/llvm-project/pull/87696 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [clang] release/18.x: [Headers] Don't declare unreachable() from stddef.h in C++ (#86748) (PR #87696)
ian-twilightcoder wrote: @tstellar is there anything else I need to do for this one? https://github.com/llvm/llvm-project/pull/87696 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [libcxx] release/18.x: [libc++] Simplify the implementation of (#86843) (PR #87374)
ian-twilightcoder wrote: Well, I wish I would've known that. We cherry-picked it because it's a regression that was introduced in LLVM 18, and I am worried that it will cause issues on some platforms. https://github.com/llvm/llvm-project/pull/87374 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [libcxx] release/18.x: [libc++] Fix -Wgnu-include-next in stddef.h (#88214) (PR #88419)
https://github.com/ian-twilightcoder approved this pull request. https://github.com/llvm/llvm-project/pull/88419 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [libcxx] release/18.x: [libc++] Fix -Wgnu-include-next in stddef.h (#88214) (PR #88419)
ian-twilightcoder wrote: We should take this in LLVM 18 because it's a regression from https://github.com/llvm/llvm-project/pull/87374 https://github.com/llvm/llvm-project/pull/88419 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [libcxx] release/18.x: [libc++] Fix -Wgnu-include-next in stddef.h (#88214) (PR #88421)
https://github.com/ian-twilightcoder closed https://github.com/llvm/llvm-project/pull/88421 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [libcxx] release/18.x: [libc++] Fix -Wgnu-include-next in stddef.h (#88214) (PR #88421)
ian-twilightcoder wrote: Already covered by https://github.com/llvm/llvm-project/pull/88419 https://github.com/llvm/llvm-project/pull/88421 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [libcxx] release/18.x: [libc++] Simplify the implementation of (#86843) (PR #87374)
ian-twilightcoder wrote: I don't think this needs a release note, it's a pretty minor change. https://github.com/llvm/llvm-project/pull/87374 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [clang] release/18.x: [Headers] Don't declare unreachable() from stddef.h in C++ (#86748) (PR #87696)
ian-twilightcoder wrote: I don't think we need to release note this one, it's just restoring LLVM 17 behavior. https://github.com/llvm/llvm-project/pull/87696 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [clang] [18.x][Docs] Add release note about Clang-defined target OS macros (PR #80044)
https://github.com/ian-twilightcoder approved this pull request. https://github.com/llvm/llvm-project/pull/80044 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [libcxx] release/20.x: [libc++][test] Backport test skipping for Apple Clang 17 (PR #131506)
https://github.com/ian-twilightcoder approved this pull request. https://github.com/llvm/llvm-project/pull/131506 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [libcxx] release/20.x: [libcxx] Add a missing include for __bit_iterator (#127015) (PR #131382)
ian-twilightcoder wrote: > This still has some failing tests. I think they should pass after https://github.com/llvm/llvm-project/pull/131506, re-running https://github.com/llvm/llvm-project/pull/131382 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
