[clang] 2ae0905 - [C23] Claim we do not conform to N2819
Author: Aaron Ballman
Date: 2024-06-24T15:09:20-04:00
New Revision: 2ae09052477e1a966afbc5482d88585f95694c53
URL:
https://github.com/llvm/llvm-project/commit/2ae09052477e1a966afbc5482d88585f95694c53
DIFF:
https://github.com/llvm/llvm-project/commit/2ae09052477e1a966afbc5482d88585f95694c53.diff
LOG: [C23] Claim we do not conform to N2819
This paper clarified the lifetime of compound literal objects in odd
scopes, such as use at function prototype scope.
We do not currently implement this paper, as the new test demonstrates.
Added:
clang/test/C/C2x/n2819.c
Modified:
clang/www/c_status.html
Removed:
diff --git a/clang/test/C/C2x/n2819.c b/clang/test/C/C2x/n2819.c
new file mode 100644
index 0..c428fbba80245
--- /dev/null
+++ b/clang/test/C/C2x/n2819.c
@@ -0,0 +1,57 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
UTC_ARGS: --version 3
+// RUN: %clang_cc1 -triple=x86_64 -emit-llvm -o - -std=c23 %s | FileCheck %s
+
+/* WG14 N2819: No
+ * Disambiguate the storage class of some compound literals
+ */
+
+int *escaped;
+// CHECK-LABEL: define dso_local i32 @f(
+// CHECK-SAME: ptr noundef [[PTR:%.*]]) #[[ATTR0:[0-9]+]] {
+// CHECK-NEXT: entry:
+// CHECK-NEXT:[[PTR_ADDR:%.*]] = alloca ptr, align 8
+// CHECK-NEXT:store ptr [[PTR]], ptr [[PTR_ADDR]], align 8
+// CHECK-NEXT:[[TMP0:%.*]] = load ptr, ptr [[PTR_ADDR]], align 8
+// CHECK-NEXT:store ptr [[TMP0]], ptr @escaped, align 8
+// CHECK-NEXT:ret i32 1
+//
+int f(int *ptr) { escaped = ptr; return 1; }
+
+// CHECK-LABEL: define dso_local i32 @g(
+// CHECK-SAME: ptr noundef [[PARA:%.*]]) #[[ATTR0]] {
+// CHECK-NEXT: entry:
+// CHECK-NEXT:[[PARA_ADDR:%.*]] = alloca ptr, align 8
+// CHECK-NEXT:store ptr [[PARA]], ptr [[PARA_ADDR]], align 8
+// CHECK-NEXT:[[CALL:%.*]] = call i32 @f(ptr noundef @.compoundliteral)
+// CHECK-NEXT:[[TMP0:%.*]] = zext i32 [[CALL]] to i64
+// CHECK-NEXT:ret i32 0
+//
+// FIXME: notice the we are using the global .compoundliteral object, not
+// allocating a new object on each call to g(). That's what was clarified by
+// N2819.
+int g(char *para [f(( int [27]) { 0 })]) {
+ return 0;
+}
+
+// CHECK-LABEL: define dso_local i32 @main(
+// CHECK-SAME: ) #[[ATTR0]] {
+// CHECK-NEXT: entry:
+// CHECK-NEXT:[[RETVAL:%.*]] = alloca i32, align 4
+// CHECK-NEXT:store i32 0, ptr [[RETVAL]], align 4
+// CHECK-NEXT:[[CALL:%.*]] = call i32 @g(ptr noundef null)
+// CHECK-NEXT:[[TMP0:%.*]] = load ptr, ptr @escaped, align 8
+// CHECK-NEXT:store i32 12, ptr [[TMP0]], align 4
+// CHECK-NEXT:[[TMP1:%.*]] = load ptr, ptr @escaped, align 8
+// CHECK-NEXT:[[TMP2:%.*]] = load i32, ptr [[TMP1]], align 4
+// CHECK-NEXT:ret i32 [[TMP2]]
+//
+int main() {
+ // Sets 'escaped' to the address of the array created by the compound
literal.
+ g(nullptr);
+
+ // The lifetime of that object should have ended when g() returned, so this
+ // should be a use-after-free.
+ *escaped = 12;
+ return *escaped;
+}
+
diff --git a/clang/www/c_status.html b/clang/www/c_status.html
index 434c9e20011d4..25656c0304da1 100644
--- a/clang/www/c_status.html
+++ b/clang/www/c_status.html
@@ -1025,7 +1025,7 @@ C23 implementation status
Disambiguate the storage class of some compound literals
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2819.pdf;>N2819
- Unknown
+ No
Add annotations for unreachable control flow v2
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Update Clang extension criteria (PR #96532)
https://github.com/AaronBallman closed https://github.com/llvm/llvm-project/pull/96532 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Update Clang extension criteria (PR #96532)
https://github.com/AaronBallman created https://github.com/llvm/llvm-project/pull/96532 This updates Clang's extension criteria to explicitly mention impacts on other projects within the monorepo. These changes were discussed in the following RFC: https://discourse.llvm.org/t/rfc-require-discussion-of-impact-to-monorepo-stakeholders-when-adding-new-clang-extensions/79613 >From a9663aca9fd5454eef2ea36284c6c690d1e44a12 Mon Sep 17 00:00:00 2001 From: Aaron Ballman Date: Mon, 24 Jun 2024 14:25:39 -0400 Subject: [PATCH] Update Clang extension criteria This updates Clang's extension criteria to explicitly mention impacts on other projects within the monorepo. These changes were discussed in the following RFC: https://discourse.llvm.org/t/rfc-require-discussion-of-impact-to-monorepo-stakeholders-when-adding-new-clang-extensions/79613 --- clang/www/get_involved.html | 6 ++ 1 file changed, 6 insertions(+) diff --git a/clang/www/get_involved.html b/clang/www/get_involved.html index 3fc688837d0bc..99fa03abb6234 100755 --- a/clang/www/get_involved.html +++ b/clang/www/get_involved.html @@ -126,6 +126,12 @@ Contributing Extensions to Clang extension is not broken by ongoing maintenance in Clang. The test suite should be complete enough that another compiler vendor could conceivably validate their implementation of the feature against it. + + A support story for other impacted projects within the monorepo: If the + extension can impact other parts of the project (libc++, lldb, compiler-rt, + etc), the proposal needs to document the impact for these projects to fully + support the extension and what level of support is expected. The impacted + project communities need to agree with that plan. ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] added regcall struct by reg support (PR #95257)
AaronBallman wrote: > I don't have any context beyond what's written on > https://reviews.llvm.org/D25204 . And at this point, I'm not sure what > compiler we're trying to be compatible with. (I added @erichkeane in case he > remembers.) The original feature was written for compatibility with ICC and the fixes are also for compatibility with ICC. > Do you know why currently clang does not do that ? is there different version > of regcall spec it follows? I suspect this was an oversight, but @erichkeane may recall more specific details (note, he's out on leave until Sept, so I don't expect to hear back from him any time soon). AFAIK, the spec you linked is the correct one for us to follow. > Also if we add new regcall struct implementation, would that break binaries > across clang version? It would be an ABI break because we'd start passing structures differently. However, we have ABI tags; we can implement the new functionality under an ABI tag so users can get the old ABI still if they need to (search for `AbiTagAttr` to see examples of how we do this elsewhere and how we test for it). https://github.com/llvm/llvm-project/pull/95257 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [MS ABI]: Support preserve_none in MS ABI (PR #96487)
https://github.com/AaronBallman approved this pull request. Generally LGTM, though the changes should come with a release note in `clang/docs/ReleaseNotes.rst` so users know about the fix. https://github.com/llvm/llvm-project/pull/96487 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [MS ABI]: Support preserve_none in MS ABI (PR #96487)
https://github.com/AaronBallman edited https://github.com/llvm/llvm-project/pull/96487 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] 3e36dfa - [C23] Remove WG14 N2660 from the list of papers we track
Author: Aaron Ballman Date: 2024-06-24T11:12:18-04:00 New Revision: 3e36dfafa0d11b2a5d7776d88f170c449116aa0e URL: https://github.com/llvm/llvm-project/commit/3e36dfafa0d11b2a5d7776d88f170c449116aa0e DIFF: https://github.com/llvm/llvm-project/commit/3e36dfafa0d11b2a5d7776d88f170c449116aa0e.diff LOG: [C23] Remove WG14 N2660 from the list of papers we track This paper was a clarification paper that made no normative changes to the wording, so we can lean on the C99 status for this. Added: Modified: clang/www/c_status.html Removed: diff --git a/clang/www/c_status.html b/clang/www/c_status.html index f6a92d94874a5..434c9e20011d4 100644 --- a/clang/www/c_status.html +++ b/clang/www/c_status.html @@ -642,11 +642,6 @@ C23 implementation status https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2186.pdf;>N2186 Unknown - - Clarifying the restrict Keyword v2 - https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2260.pdf;>N2660 - Unknown - Harmonizing static_assert with C++ https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2265.pdf;>N2665 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] b012ab0 - [C23] Claim conformance to WG14 N3033
Author: Aaron Ballman
Date: 2024-06-24T10:52:17-04:00
New Revision: b012ab01cb39e440a38dad5d7dd71b419480264b
URL:
https://github.com/llvm/llvm-project/commit/b012ab01cb39e440a38dad5d7dd71b419480264b
DIFF:
https://github.com/llvm/llvm-project/commit/b012ab01cb39e440a38dad5d7dd71b419480264b.diff
LOG: [C23] Claim conformance to WG14 N3033
Clang has implemented __VA_OPT__ since Clang 12.
Added:
clang/test/C/C2x/n3033.c
clang/test/C/C2x/n3033_2.c
Modified:
clang/www/c_status.html
Removed:
diff --git a/clang/test/C/C2x/n3033.c b/clang/test/C/C2x/n3033.c
new file mode 100644
index 0..bf249a37facb3
--- /dev/null
+++ b/clang/test/C/C2x/n3033.c
@@ -0,0 +1,50 @@
+// RUN: %clang_cc1 -std=c23 -E %s | FileCheck %s
+
+/* WG14 N3033: Clang 12
+ * Comma ommission and deletion (__VA_OPT__)
+ */
+
+#define F(...) f(0 __VA_OPT__(,) __VA_ARGS__)
+#define G(X, ...)f(0, X __VA_OPT__(,) __VA_ARGS__)
+#define SDEF(sname, ...) S sname __VA_OPT__(= { __VA_ARGS__ })
+#define EMP
+
+F(a, b, c)// replaced by f(0, a, b, c)
+// CHECK: f(0 , a, b, c)
+F() // replaced by f(0)
+// CHECK: f(0 )
+F(EMP)// replaced by f(0)
+// CHECK: f(0 )
+
+G(a, b, c)// replaced by f(0, a, b, c)
+// CHECK: f(0, a , b, c)
+G(a, )// replaced by f(0, a)
+// CHECK: f(0, a )
+G(a) // replaced by f(0, a)
+// CHECK: f(0, a )
+
+SDEF(foo);// replaced by S foo;
+// CHECK: S foo ;
+SDEF(bar, 1, 2); // replaced by S bar = { 1, 2 };
+// CHECK: S bar = { 1, 2 };
+
+//#define H1(X, ...) X __VA_OPT__(##) __VA_ARGS__ // error: ## may not
appear at the beginning of a replacement list (6.10.3.3)
+
+#define H2(X, Y, ...)__VA_OPT__(X ## Y,) __VA_ARGS__
+H2(a, b, c, d)// replaced by ab, c, d
+// CHECK: ab, c, d
+
+#define H3(X, ...) #__VA_OPT__(X##X X##X)
+H3(, 0) // replaced by ""
+// CHECK: ""
+
+#define H4(X, ...) __VA_OPT__(a X ## X) ## b
+H4(, 1) // replaced by a b
+// CHECK: a b
+
+#define H5A(...) __VA_OPT__()/**/__VA_OPT__()
+#define H5B(X) a ## X ## b
+#define H5C(X) H5B(X)
+H5C(H5A())// replaced by ab
+// CHECK: ab
+
diff --git a/clang/test/C/C2x/n3033_2.c b/clang/test/C/C2x/n3033_2.c
new file mode 100644
index 0..5da206658690c
--- /dev/null
+++ b/clang/test/C/C2x/n3033_2.c
@@ -0,0 +1,4 @@
+// RUN: %clang_cc1 -fsyntax-only -std=c23 -verify %s
+
+#define H1(X, ...) X __VA_OPT__(##) __VA_ARGS__ // expected-error {{'##'
cannot appear at start of __VA_OPT__ argument}}
+
diff --git a/clang/www/c_status.html b/clang/www/c_status.html
index 6b375a6b7999d..f6a92d94874a5 100644
--- a/clang/www/c_status.html
+++ b/clang/www/c_status.html
@@ -1184,7 +1184,7 @@ C23 implementation status
Comma ommission and deletion (__VA_OPT__)
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3033.htm;>N3033
- Unknown
+ Clang 12
Underspecified object definitions
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang][ThreadSafety] Fix code block syntax in ThreadSafetyAnalysis.rst (PR #96494)
https://github.com/AaronBallman closed https://github.com/llvm/llvm-project/pull/96494 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang][ThreadSafety] Fix code block syntax in ThreadSafetyAnalysis.rst (PR #96494)
https://github.com/AaronBallman approved this pull request. LGTM, thanks for the quick fix! https://github.com/llvm/llvm-project/pull/96494 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] 6ecb9fd - [C11] Remove WG14 N1382 from the list of papers to track
Author: Aaron Ballman Date: 2024-06-24T10:34:11-04:00 New Revision: 6ecb9fd83d6015b19be8db554328645ae15e63e9 URL: https://github.com/llvm/llvm-project/commit/6ecb9fd83d6015b19be8db554328645ae15e63e9 DIFF: https://github.com/llvm/llvm-project/commit/6ecb9fd83d6015b19be8db554328645ae15e63e9.diff LOG: [C11] Remove WG14 N1382 from the list of papers to track This paper proposes only changes to a footnote that had problematic implications for ABI; the changes were purely editorial. Added: Modified: clang/www/c_status.html Removed: diff --git a/clang/www/c_status.html b/clang/www/c_status.html index 4cbb51ea02468..6b375a6b7999d 100644 --- a/clang/www/c_status.html +++ b/clang/www/c_status.html @@ -488,11 +488,6 @@ C11 implementation status https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1367.htm;>N1367 Unknown - - FLT_EVAL_METHOD and return - https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1382.htm;>N1382 - Unknown - Floating-point to int/_Bool conversions https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1391.htm;>N1391 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] 29e0f04 - [C11] Remove WG14 N1353 from the list of papers to track
Author: Aaron Ballman Date: 2024-06-24T10:29:15-04:00 New Revision: 29e0f046735010540fbdba4371dcd26f9e437650 URL: https://github.com/llvm/llvm-project/commit/29e0f046735010540fbdba4371dcd26f9e437650 DIFF: https://github.com/llvm/llvm-project/commit/29e0f046735010540fbdba4371dcd26f9e437650.diff LOG: [C11] Remove WG14 N1353 from the list of papers to track Only the first proposed changes in the paper were adopted, and that wording was changing "operations" into "operators", which is purely an editorial change. Added: Modified: clang/www/c_status.html Removed: diff --git a/clang/www/c_status.html b/clang/www/c_status.html index 922a84ca34312..4cbb51ea02468 100644 --- a/clang/www/c_status.html +++ b/clang/www/c_status.html @@ -457,11 +457,6 @@ C11 implementation status https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1349.htm;>N1349 Unknown - - FLT_EVAL_METHOD issues (first change only) - https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1353.pdf;>N1353 - Unknown - _Bool bit-fields https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1356.htm;>N1356 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] 3ff680a - [C11] Claim we do not conform to WG14 N1285 yet
Author: Aaron Ballman
Date: 2024-06-24T09:50:37-04:00
New Revision: 3ff680a1a57d74a5c94d3da35594a8046a879888
URL:
https://github.com/llvm/llvm-project/commit/3ff680a1a57d74a5c94d3da35594a8046a879888
DIFF:
https://github.com/llvm/llvm-project/commit/3ff680a1a57d74a5c94d3da35594a8046a879888.diff
LOG: [C11] Claim we do not conform to WG14 N1285 yet
This also updates the status for C11 to be Partial, and because C17 is
C11 plus DR resolutions, that makes C17 also Partial.
Added:
clang/test/C/C11/n1285.c
Modified:
clang/www/c_status.html
Removed:
diff --git a/clang/test/C/C11/n1285.c b/clang/test/C/C11/n1285.c
new file mode 100644
index 0..e7a9463e68103
--- /dev/null
+++ b/clang/test/C/C11/n1285.c
@@ -0,0 +1,24 @@
+// RUN: %clang_cc1 -verify=wrong -std=c99 %s
+// RUN: %clang_cc1 -verify=wrong -std=c11 %s
+// RUN: %clang_cc1 -verify=cpp -std=c++11 -x c++ %s
+
+/* WG14 N1285: No
+ * Extending the lifetime of temporary objects (factored approach)
+ *
+ * NB: we do not properly materialize temporary expressions in situations where
+ * it would be expected; that is why the "no-diagnostics" marking is named
+ * "wrong". We do issue the expected diagnostic in C++ mode.
+ */
+
+// wrong-no-diagnostics
+
+struct X { int a[5]; };
+struct X f(void);
+
+int foo(void) {
+ // FIXME: This diagnostic should be issued in C11 as well (though not in C99,
+ // as this paper was a breaking change between C99 and C11).
+ int *p = f().a; // cpp-warning {{temporary whose address is used as value of
local variable 'p' will be destroyed at the end of the full-expression}}
+ return *p;
+}
+
diff --git a/clang/www/c_status.html b/clang/www/c_status.html
index d71d4c216f744..922a84ca34312 100644
--- a/clang/www/c_status.html
+++ b/clang/www/c_status.html
@@ -57,12 +57,12 @@ C Support in Clang
C11
-std=c11
- Probably
+ Partial
C17
-std=c17
- Maybe?
+ Partial
C23
@@ -425,7 +425,7 @@ C11 implementation status
Extending the lifetime of temporary objects (factored approach)
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1285.htm;>N1285
- Unknown
+ No
Requiring signed char to have no padding bits
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang][ThreadSafety] Check trylock function success and return types (PR #95290)
https://github.com/AaronBallman closed https://github.com/llvm/llvm-project/pull/95290 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang][ThreadSafety] Check trylock function success and return types (PR #95290)
https://github.com/AaronBallman approved this pull request. LGTM still https://github.com/llvm/llvm-project/pull/95290 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang][Sema] Fix crash on atomic builtins with incomplete type args (PR #96374)
@@ -4570,7 +4570,8 @@ ExprResult Sema::BuildAtomicExpr(SourceRange CallRange,
SourceRange ExprRange,
}
// Pointer to object of size zero is not allowed.
- if (Context.getTypeInfoInChars(AtomTy).Width.isZero()) {
+ if (!AtomTy->isIncompleteType() &&
AaronBallman wrote:
If you call `RequireCompleteType()` before this `if` instead of checking for an
incomplete type, do you get better diagnostic behavior?
https://github.com/llvm/llvm-project/pull/96374
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang][Sema] Fix crash on atomic builtins with incomplete type args (PR #96374)
https://github.com/AaronBallman commented: Thank you for the fix! The changes should also come with a release note in `clang/docs/ReleaseNotes.rst` so users know about the improvement. https://github.com/llvm/llvm-project/pull/96374 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang][Sema] Fix crash on atomic builtins with incomplete type args (PR #96374)
https://github.com/AaronBallman edited https://github.com/llvm/llvm-project/pull/96374 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] nonblocking/nonallocating attributes (was: nolock/noalloc) (PR #84983)
AaronBallman wrote: > Given that this is for a clang extension and not a conformance issue, I'm > inclined to revert. > > It might make sense to do that, yeah. Either way, we should investigate > what’s going on here. @AaronBallman wdyt? Definitely worth investigating, unsure whether this is sufficiently disruptive to warrant a revert as opposed to a fix forward. I don't oppose a revert if @nikic would like to see one, but I realize now that we have no wording in our revert policy regarding incremental compile time performance regressions (if it was a huge regression, I think it falls under correctness, but this is a relatively small change in performance and no bots are red as a result either). So if we think this warrants a revert, should we consider updating the policy to more clearly state when to revert for performance reasons? https://github.com/llvm/llvm-project/pull/84983 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] clang: Relax LangOpts checks when lexing quoted numbers during preprocessing (PR #95798)
@@ -2068,7 +2068,8 @@ bool Lexer::LexNumericConstant(Token , const char
*CurPtr) {
}
// If we have a digit separator, continue.
- if (C == '\'' && (LangOpts.CPlusPlus14 || LangOpts.C23)) {
+ if (C == '\'' &&
+ (LangOpts.CPlusPlus14 || LangOpts.C23 || ParsingPreprocessorDirective)) {
AaronBallman wrote:
I'm not certain that's a pattern we should get into -- we don't want a
`LangOption` per language feature shared between languages unless it's
something the user can enable or disable themselves via the command line.
https://github.com/llvm/llvm-project/pull/95798
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Pass LangOpts from CompilerInstance to DependencyScanningWorker (PR #93753)
AaronBallman wrote: > > > > I guess the general question is - is it acceptable to have the Scanner > > > > operating in a language standard different than the passed in language > > > > mode and different than the compiler language standard? > > > > > > > > > I think that is acceptable. It is kinda hacky, but the lexer and > > > preprocessor are largely independent of the language and the standard. > > > When they do depend on those settings, taking the union of the features > > > and letting the compiler trim it down is still a perfectly sound thing to > > > do. > > > > > > You can certainly construct cases where the different lexing rules in > > different language modes allow you to detect which language you're in from > > within the preprocessor ([1](https://eel.is/c++draft/diff.cpp11.lex) > > [2](https://eel.is/c++draft/diff.cpp14.lex#2) > > [3](https://eel.is/c++draft/diff.cpp03.lex#1)) or where enabling more > > language mode flags may reject valid code. It may be good enough for what > > the scanner is trying to do, but I think it's a stretch to say that it's > > sound. > > +1; it's definitely not sound to go this approach, though it may work well > enough in practice to be worth the tradeoff. That said, I think the behavior > of the dependency scanner ignoring the language options used is actually kind > of problematic, unless I'm misunderstanding something. This means command > line options that impact dependency scanning may fail (for example, the user > might enable SYCL or OpenMP on the command line and that may have different > dependencies, trigraph support may be important for things like `??=include`, > freestanding vs not impacts which preprocessor macros are predefined, etc. > How do we handle that sort of stuff, or do we just ignore it? Ping @jansvoboda11 https://github.com/llvm/llvm-project/pull/93753 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] 918ef31 - [C99] Claim full conformance to C99
Author: Aaron Ballman Date: 2024-06-21T13:47:57-04:00 New Revision: 918ef312d1fda56ff783f3974b5a193542e5497c URL: https://github.com/llvm/llvm-project/commit/918ef312d1fda56ff783f3974b5a193542e5497c DIFF: https://github.com/llvm/llvm-project/commit/918ef312d1fda56ff783f3974b5a193542e5497c.diff LOG: [C99] Claim full conformance to C99 We now believe we know the status of all the proposals that went into C99. There are three entries marked Partial: N448 restricted pointers Clang fully conforms to the standard requirements, but LLVM support could be improved to support more than just restricted pointers used as function parameters. N693 complex and imaginary support in - Clang supports _Complex but not _Imaginary. Clang does not attempt to implement Annex G, so a lack of _Imaginary is not necessary for conformance to C99. It's also worth noting that C2y is anticipated to remove support for _Imaginary (see WG14 N3274 which was adopted at the June 2024 meeting). However, support for _Complex requires runtime support and compiler-rt is not supported on all targets (notably, Windows). (Doc # unknown) IEC 60559 support - Clang largely conforms to the requirements in Annex F, but there are edge cases that are incorrect. However, Clang does not predefine the __STDC_IEC_559__ macro and so we don't claim to conform to Annex F yet. Because all three of these partial entries are technically conforming, it seems reasonable to claim full conformance for C99. Added: Modified: clang/www/c_status.html Removed: diff --git a/clang/www/c_status.html b/clang/www/c_status.html index d8700d6bf3779..d71d4c216f744 100644 --- a/clang/www/c_status.html +++ b/clang/www/c_status.html @@ -44,7 +44,15 @@ C Support in Clang C99 -std=c99 - Almost certainly + Clang 17 + C11 @@ -63,9 +71,9 @@ C Support in Clang -The implementation status for C99, C11, C17, and C23 are currently under -investigation. Any proposal whose status in Clang is currently unknown -will be marked in magenta. +The implementation status for C11 and C23 are currently under investigation. +Any proposal whose status in Clang is currently unknown will be marked in +magenta. The Clang community is continually striving to improve C standards compliance between releases by submitting and tracking @@ -83,7 +91,7 @@ C89 implementation status C99 implementation status -Clang implements a significant portion of the ISO 9899:1999 (C99) standard, but the status of individual proposals is still under investigation. +Clang implements all of the ISO 9899:1999 (C99) standard. Note, the list of C99 features comes from the C99 committee draft. Not all C99 documents are publicly available, so the documents referenced in this section may be inaccurate, unknown, or not linked.
[clang] 131bc03 - [C99] Claim partial conformance to IEC 60559 support
Author: Aaron Ballman Date: 2024-06-21T13:28:02-04:00 New Revision: 131bc0390dba1bc21fb8af8e5e8afa78a17d39b9 URL: https://github.com/llvm/llvm-project/commit/131bc0390dba1bc21fb8af8e5e8afa78a17d39b9 DIFF: https://github.com/llvm/llvm-project/commit/131bc0390dba1bc21fb8af8e5e8afa78a17d39b9.diff LOG: [C99] Claim partial conformance to IEC 60559 support We intend to support Annex F but there are edge cases we don't handle properly, such as raising an "invalid" exception when converting some floating-point values to integers. This does not add any test coverage as full conformance would require sufficiently extensive testing that we should consider getting a third-party test suite such as the one from http://tybor.com/ Added: Modified: clang/www/c_status.html Removed: diff --git a/clang/www/c_status.html b/clang/www/c_status.html index 170ab0e1cc321..d8700d6bf3779 100644 --- a/clang/www/c_status.html +++ b/clang/www/c_status.html @@ -277,7 +277,25 @@ C99 implementation status IEC 60559 support Unknown - Unknown + +Partial + Clang supports much of the language requirements for Annex F, but + full conformance is only possible to determine when considering the + compiler's language support, the C runtime library's math library + support, and the target system's floating-point environment support. + Clang does not currently raise an "invalid" floating-point exception + on certain conversions, does not raise floating-point exceptions for + arithmetic constant expressions, and other corner cases. Note, Clang + does not define __STDC_IEC_559__ because the compiler + does not fully conform. However, some C standard library + implementations + (https://sourceware.org/git/?p=glibc.git;a=blob;f=include/stdc-predef.h;> + glibc, https://git.musl-libc.org/cgit/musl/tree/include/stdc-predef.h;> + musl will define the macro regardless of compiler support unless + the compiler defines __GCC_IEC_559, which Clang does not + currently define. + + trailing comma allowed in enum declaration ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] 19470e7 - [C99] Claim conformance to "more precise aliasing rules via effective type"
Author: Aaron Ballman Date: 2024-06-21T12:48:01-04:00 New Revision: 19470e72e4aadfe16d1b6b0e4df325d75dc7fd7c URL: https://github.com/llvm/llvm-project/commit/19470e72e4aadfe16d1b6b0e4df325d75dc7fd7c DIFF: https://github.com/llvm/llvm-project/commit/19470e72e4aadfe16d1b6b0e4df325d75dc7fd7c.diff LOG: [C99] Claim conformance to "more precise aliasing rules via effective type" We don't have a document number to check our behavior against, but the document title makes it clear that this is related to optimization behavior, which doesn't require Clang to change. Added: Modified: clang/www/c_status.html Removed: diff --git a/clang/www/c_status.html b/clang/www/c_status.html index 715bc5f024926..170ab0e1cc321 100644 --- a/clang/www/c_status.html +++ b/clang/www/c_status.html @@ -110,7 +110,7 @@ C99 implementation status more precise aliasing rules via effective type Unknown - Unknown + Yes restricted pointers ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang][ThreadSafety] Check trylock function success and return types (PR #95290)
AaronBallman wrote: > > LGTM -- that new documentation is fantastic, thank you for that! > > Thank you! I hope it saves future readers some time. > > I don't have write access, so feel free to merge unless we're waiting for > @aaronpuchert to review :) I'll give Aaron a chance to weigh in and land the changes on your behalf early next week if we don't hear back from him. https://github.com/llvm/llvm-project/pull/95290 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang][ThreadSafety] Check trylock function success and return types (PR #95290)
https://github.com/AaronBallman approved this pull request. LGTM -- that new documentation is fantastic, thank you for that! https://github.com/llvm/llvm-project/pull/95290 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang][ThreadSafety] Check trylock function success and return types (PR #95290)
https://github.com/AaronBallman edited https://github.com/llvm/llvm-project/pull/95290 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] nonblocking/nonallocating attributes (was: nolock/noalloc) (PR #84983)
https://github.com/AaronBallman approved this pull request. The only thing I think is missing is a release note in `clang/docs/ReleaseNotes.rst` so users know about the new functionality, otherwise this LGTM! https://github.com/llvm/llvm-project/pull/84983 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang] skip alignment checks on incomplete types to avoid an assertion failure while parsing lambda used as default argument (PR #94542)
https://github.com/AaronBallman closed https://github.com/llvm/llvm-project/pull/94542 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] Reland [clang][Sema, Lex, Parse] Preprocessor embed in C and C++ (PR #95802)
AaronBallman wrote: Thank you both for collaborating to get that solved! https://github.com/llvm/llvm-project/pull/95802 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang] skip alignment checks on incomplete types to avoid an assertion failure while parsing lambda used as default argument (PR #94542)
AaronBallman wrote: > @AaronBallman Thank you for your feedback. Do you think this needs to be > reviewed by someone else? I can't add reviewers myself :) Nope, it's ready to land; sorry for not asking earlier, do you need me to commit this on your behalf? https://github.com/llvm/llvm-project/pull/94542 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [BoundsSafety][doc] Make it clear that the feature is work-in-progress (PR #95964)
@@ -8,6 +8,9 @@ Overview +**NOTE:** This is a design document and the feature is not available for users yet. +Please find :doc:`BoundsSafetyImplPlans` for more details. AaronBallman wrote: ```suggestion Please see :doc:`BoundsSafetyImplPlans` for more details. ``` https://github.com/llvm/llvm-project/pull/95964 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [BoundsSafety][doc] Make it clear that the feature is work-in-progress (PR #95964)
https://github.com/AaronBallman approved this pull request. Thank you for updating the documentation, the changes LGTM (had one minor suggestion you can take or leave as you'd like). I think it's better for us to have the documentation than not, so I'm fine with this approach of letting people know about the current and future flags. https://github.com/llvm/llvm-project/pull/95964 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [BoundsSafety][doc] Make it clear that the feature is work-in-progress (PR #95964)
https://github.com/AaronBallman edited https://github.com/llvm/llvm-project/pull/95964 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] 6bc71cd - [C99] Claim partial conformance to n448
Author: Aaron Ballman
Date: 2024-06-20T13:29:36-04:00
New Revision: 6bc71cdd32de0add80d620b1342b5549efff363a
URL:
https://github.com/llvm/llvm-project/commit/6bc71cdd32de0add80d620b1342b5549efff363a
DIFF:
https://github.com/llvm/llvm-project/commit/6bc71cdd32de0add80d620b1342b5549efff363a.diff
LOG: [C99] Claim partial conformance to n448
This is the paper that added the 'restrict' keyword. Clang is
conforming to the letter of the standard's requirements, so it would be
defensible for us to claim full support instead. However, LLVM does not
currently support the optimization semantics with restricted local
variables or data members, only with restricted pointers declared in
function parameters. So we're only claiming partial support because we
don't yet take full advantage of what the feature allows.
Added:
clang/test/C/C99/n448.c
Modified:
clang/www/c_status.html
Removed:
diff --git a/clang/test/C/C99/n448.c b/clang/test/C/C99/n448.c
new file mode 100644
index 0..c9f97920b2079
--- /dev/null
+++ b/clang/test/C/C99/n448.c
@@ -0,0 +1,44 @@
+// RUN: %clang_cc1 -verify -std=c99 %s
+// RUN: %clang_cc1 -verify -std=c23 %s
+
+/* WG14 N448: Partial
+ * Restricted pointers
+ *
+ * NB: we claim partial conformance only because LLVM does not attempt to apply
+ * the semantics on local variables or structure data members; it only
+ * considers function parameters. However, Clang itself is fully conforming for
+ * this feature.
+ */
+
+// Restrict is only allowed on pointers.
+int * restrict ipr;
+int restrict ir; // expected-error {{restrict requires a pointer or reference
('int' is invalid)}}
+
+// Restrict only applies to object pointers.
+void (* restrict fp)(void); // expected-error {{pointer to function type 'void
(void)' may not be 'restrict' qualified}}
+
+typedef int *int_ptr;
+int_ptr restrict ipr2; // okay, still applied to the pointer.
+
+// Show that the qualifer is dropped on lvalue conversion
+_Static_assert(
+ _Generic(ipr,
+int * : 1,
+int * restrict : 0, // expected-warning {{due to lvalue conversion of the
controlling expression, association of type 'int *restrict' will never be
selected because it is qualified}}
+default : 0),
+ "");
+
+// Show that it's allowed as a qualifier for array parameters.
+void f(int array[restrict]) {
+ int *ipnr = ipr; // okay to drop the top-level qualifier
+
+ // Show that it's not okay to drop the qualifier when it's not at the top
level.
+ int * restrict * restrict iprpr;
+ int **ipp = iprpr;// expected-warning {{initializing 'int **'
with an expression of type 'int *restrict *restrict' discards qualifiers}}
+ int ** restrict ippr = iprpr; // expected-warning {{initializing 'int
**restrict' with an expression of type 'int *restrict *restrict' discards
qualifiers}}
+}
+
+#if __STDC_VERSION__ >= 202311L
+// C23 doesn't allow constexpr to mix with restrict. See C23 6.7.2p5.
+constexpr int * restrict ip; // expected-error {{constexpr variable cannot
have type 'int *const restrict'}}
+#endif // __STDC_VERSION__ >= 202311L
diff --git a/clang/www/c_status.html b/clang/www/c_status.html
index b691bcf6bee9c..715bc5f024926 100644
--- a/clang/www/c_status.html
+++ b/clang/www/c_status.html
@@ -115,7 +115,16 @@ C99 implementation status
restricted pointers
N448
- Unknown
+
+Partial
+ Clang's support for restrict is fully conforming but
+ considered only partially implemented. Clang implements all of the
+ constraints required for restrict support, but LLVM only
+ supports restrict optimization semantics for restricted
+ pointers used as function parameters; it does not fully support the
+ semantics for restrict on local variables or data members.
+
+
variable length arrays
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [lldb] [clang][AST] fix ast-print of extern with >=2 declarators, fixed (PR #93913)
AaronBallman wrote: Do you need someone to land these changes on your behalf? https://github.com/llvm/llvm-project/pull/93913 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [BoundsSafety] Add `-fexperimental-bounds-safety` CC1 and language option and use it to tweak `counted_by`'s semantics (PR #92623)
https://github.com/AaronBallman approved this pull request. LGTM; when we add `-fbounds-safety` in the future, we may want the language option to become an enumeration so we can distinguish between the experimental, non-experimental, and disabled bounds safety options, but we can cross that bridge when we get to it. https://github.com/llvm/llvm-project/pull/92623 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [BoundsSafety] Add `-fexperimental-bounds-safety` CC1 and language option and use it to tweak `counted_by`'s semantics (PR #92623)
AaronBallman wrote: > @AaronBallman We haven't exposed the `-fbounds-safety` flag yet. The idea was > to guard it under the experimental flag called `-fexperimental-bounds-safety` > as a CC1 flag for testing until we have the full feature available (the > feature is work-in-progress and is going to take some time to implement). > Then, we would create `-fbounds-safety` to be exposed as driver and CC1 > flags. We would deprecate `-fexperimental-bounds-safety` after that point but > might have to keep as an alias of `-fbounds-safety` for a release so people > can switch over to `-fbounds-safety`. > > Does it sound like a reasonable strategy to you? Please let us know if you > have other preference. Ah, thank you for the explanation! That sounds like a reasonable strategy to me; I was mostly worried that we'd be exposing two driver flags for this and it wasn't clear what the distinction was. But for a CC1 flag to enable testing and for early adopters, it seems reasonable. Thanks! https://github.com/llvm/llvm-project/pull/92623 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang] Allow raw string literals in C as an extension (PR #88265)
https://github.com/AaronBallman approved this pull request. Clang changes LGTM modulo the dependency scanner bits. https://github.com/llvm/llvm-project/pull/88265 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang] Allow raw string literals in C as an extension (PR #88265)
AaronBallman wrote: > > Why gnu99 mode and not gnu89 mode? I see GCC has that behavior, but I'm not > > certain why. > > We went over this a while back: [#88265 > (comment)](https://github.com/llvm/llvm-project/pull/88265#discussion_r1571088366) THAT is why this was so familiar to me! :-D Thanks! https://github.com/llvm/llvm-project/pull/88265 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [NFC]Fix memory leak in HeaderSearchTest (PR #95927)
AaronBallman wrote: Thank you for the fix! FWIW, I don't think this is NFC as it is changing test behavior (fixing a memory leak); please be sure to get a proper code review for functional changes. The changes are reasonable enough, but one question I have is: why not stack allocate the object rather than heap allocate it? https://github.com/llvm/llvm-project/pull/95927 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang][Comments] Support for parsing headers in Doxygen \par commands (PR #91100)
https://github.com/AaronBallman closed https://github.com/llvm/llvm-project/pull/91100 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang] Add test for CWG2811 "Clarify "use" of main" (PR #96168)
@@ -964,7 +964,7 @@ def err_main_global_variable : def warn_main_redefined : Warning<"variable named 'main' with external linkage " "has undefined behavior">, InGroup; def ext_main_used : Extension< - "ISO C++ does not allow 'main' to be used by a program">, InGroup; + "expressions that refer to 'main' are an extension">, InGroup; AaronBallman wrote: Good point about `decltype` accepting an expression. This is fine by me. https://github.com/llvm/llvm-project/pull/96168 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang] Add test for CWG2811 "Clarify "use" of main" (PR #96168)
https://github.com/AaronBallman approved this pull request. LGTM! https://github.com/llvm/llvm-project/pull/96168 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] 40a0ad2 - [C11] Claim conformance to WG14 N3159
Author: Aaron Ballman Date: 2024-06-20T10:26:13-04:00 New Revision: 40a0ad2af3b6305fbabec003e51dad62564aa019 URL: https://github.com/llvm/llvm-project/commit/40a0ad2af3b6305fbabec003e51dad62564aa019 DIFF: https://github.com/llvm/llvm-project/commit/40a0ad2af3b6305fbabec003e51dad62564aa019.diff LOG: [C11] Claim conformance to WG14 N3159 This was a roll-up of defect reports that we already test elsewhere, so no additional test coverage is needed. DR345: tested by clang/test/C/drs/dr3xx.c DR344: tested by clang/test/C/drs/dr3xx.c DR343: tested by clang/test/C/drs/dr3xx.c DR341: tested by clang/test/C/drs/dr3xx.c DR340: tested by clang/test/C/drs/dr3xx.c DR338: tested by clang/test/C/drs/dr338.c DR336: N/A for the compiler DR330: N/A for the compiler DR329: N/A for the compiler DR328: tested by clang/test/C/drs/dr3xx.c DR327: editorial DR326: N/A for the compiler DR315: tested by clang/test/C/drs/dr3xx.c Added: Modified: clang/www/c_status.html Removed: diff --git a/clang/www/c_status.html b/clang/www/c_status.html index 562a631949637..b691bcf6bee9c 100644 --- a/clang/www/c_status.html +++ b/clang/www/c_status.html @@ -435,7 +435,8 @@ C11 implementation status Technical corrigendum for C1X https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1359.htm;>N1359 - Unknown + Yes + Benign typedef redefinition ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] b84323c - [C11] Remove N1350 and N1394 from the list of documents on the C status page
Author: Aaron Ballman Date: 2024-06-20T10:02:22-04:00 New Revision: b84323cca9e2c7049c0aec92a45911742822b40e URL: https://github.com/llvm/llvm-project/commit/b84323cca9e2c7049c0aec92a45911742822b40e DIFF: https://github.com/llvm/llvm-project/commit/b84323cca9e2c7049c0aec92a45911742822b40e.diff LOG: [C11] Remove N1350 and N1394 from the list of documents on the C status page These papers added Annex K, which is a library component that Clang doesn't need to do anything to support. Added: Modified: clang/www/c_status.html Removed: diff --git a/clang/www/c_status.html b/clang/www/c_status.html index 7fe633aa7e446..562a631949637 100644 --- a/clang/www/c_status.html +++ b/clang/www/c_status.html @@ -422,11 +422,6 @@ C11 implementation status https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1349.htm;>N1349 Unknown - - Analyzability (#1, #4 - conditionally normative) - https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1350.htm;>N1350 - Unknown - FLT_EVAL_METHOD issues (first change only) https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1353.pdf;>N1353 @@ -472,11 +467,6 @@ C11 implementation status https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1391.htm;>N1391 Yes - - Analyzability (along the lines) - https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1394.htm;>N1394 - Unknown - Wide function returns (alternate proposal) https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1396.htm;>N1396 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang][Comments] Attach comments to decl even if preproc directives are in between (PR #88367)
https://github.com/AaronBallman edited https://github.com/llvm/llvm-project/pull/88367 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang][Comments] Attach comments to decl even if preproc directives are in between (PR #88367)
https://github.com/AaronBallman approved this pull request. LGTM! https://github.com/llvm/llvm-project/pull/88367 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang] Allow raw string literals in C as an extension (PR #88265)
AaronBallman wrote: > raw string literals are enabled in C++11 and later, as well as in C in gnu99 > mode and later; Why gnu99 mode and not gnu89 mode? I see GCC has that behavior, but I'm not certain why. > I’m not entirely sure how to fix this candidly. It doesn’t look like > unconditionally enabling raw string literals is an option here... This > situation reminds me of a similar issue we’re having with ' in numeric > literals (#88896). I’m personally not too familiar with the lexer, but would > it be possible to pass through the original lang options here from wherever > this is invoked? Yeah, it's pretty frustrating that we've found two instances of this in such a short period of time. :-/ That test was added in https://github.com/llvm/llvm-project/commit/ee8ed0b3099e63ba0a18cca42b9cfdf098bc6201 and it seems to be a bit of a drive-by as the author noticed the behavior. Given that dependency scanning is never going to care about raw string literals to begin with (at least that I can think of), I'm not certain there's any harm in always supporting raw string literals from dependency scanning, so we could probably do that in the worst case. But my concerns from https://github.com/llvm/llvm-project/pull/93753#issuecomment-217302 are still relevant too. CC @jansvoboda11 https://github.com/llvm/llvm-project/pull/88265 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] [ubsan] Display correct runtime messages for negative _BitInt (PR #93612)
https://github.com/AaronBallman edited https://github.com/llvm/llvm-project/pull/93612 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] [ubsan] Display correct runtime messages for negative _BitInt (PR #93612)
https://github.com/AaronBallman approved this pull request. LGTM https://github.com/llvm/llvm-project/pull/93612 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] nonblocking/nonallocating attributes (was: nolock/noalloc) (PR #84983)
https://github.com/AaronBallman edited https://github.com/llvm/llvm-project/pull/84983 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang] Add test for CWG2811 "Clarify "use" of main" (PR #96168)
@@ -964,7 +964,7 @@ def err_main_global_variable :
def warn_main_redefined : Warning<"variable named 'main' with external linkage
"
"has undefined behavior">, InGroup;
def ext_main_used : Extension<
- "ISO C++ does not allow 'main' to be used by a program">, InGroup;
+ "expressions that refer to 'main' are an extension">, InGroup;
AaronBallman wrote:
```suggestion
"expressions that refer to 'main' are a Clang extension">, InGroup;
```
I think there's work to be done for full conformance here though. For example,
this DR clarified that the following code is valid, but we still diagnose it as
an extension:
```
int main() {}
decltype(main) maine;
```
https://godbolt.org/z/nn8rd483Y
https://github.com/llvm/llvm-project/pull/96168
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang] Fix parsing of reversible type traits in template arguments (PR #95969)
@@ -141,3 +141,15 @@ namespace r360308_regression {
return a == b;
}
}
+
+namespace GH95598 {
+template
+struct __is_pointer {};
+// expected-warning@-1 {{keyword '__is_pointer' will be made available as an
identifier for the remainder of the translation unit}}
AaronBallman wrote:
Thanks for the historical information @zygoloid!
> I don't think we should be extending this hack further. I've suggested on the
> libstdc++ bug report that this be fixed in libstdc++ instead, by stopping
> using our keywords as their type names. Maybe one day we can then remove it
> entirely.
I tend to agree; if we can avoid continuing to extend this hack, I think we
should. That said, I'd be curious whether deprecation is highly disruptive or
not; my intuition is that we'd struggle with this one because people tend to
use boost (and certainly libstdc++) as system headers, and we suppress
diagnostics by default in system headers. So I'd expect this deprecation to
take a *long* while before we could remove the hacks due to the long tail of
not wanting to break system headers.
The ctor situation would be annoying, but I think the ctor and dtor are the
only places we'd have to put in a special hack for "got a keyword where we
expected an identifier", so perhaps the blast radius is sufficiently limited
for that to be a reasonable approach?
https://github.com/llvm/llvm-project/pull/95969
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang] Change style of superseded issues on C++ DR status page (PR #96051)
https://github.com/AaronBallman approved this pull request. LGTM, thank you, I love it! https://github.com/llvm/llvm-project/pull/96051 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] Reland [clang][Sema, Lex, Parse] Preprocessor embed in C and C++ (PR #95802)
https://github.com/AaronBallman approved this pull request. Leak fix LGTM, I think it's ready to re-land and try again. https://github.com/llvm/llvm-project/pull/95802 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] Reland [clang][Sema, Lex, Parse] Preprocessor embed in C and C++ (PR #95802)
@@ -0,0 +1,98 @@
+// RUN: %clang_cc1 %s -fsyntax-only --embed-dir=%S/Inputs -verify=expected,cxx
-Wno-c23-extensions
+// RUN: %clang_cc1 -x c -std=c23 %s -fsyntax-only --embed-dir=%S/Inputs
-verify=expected,c
+#embed
+;
+
+void f (unsigned char x) { (void)x;}
+void g () {}
+void h (unsigned char x, int y) {(void)x; (void)y;}
+int i () {
+ return
+#embed
+ ;
+}
+
+_Static_assert(
+#embed suffix(,)
+""
+);
+_Static_assert(
+#embed
+, ""
+);
+_Static_assert(sizeof(
+#embed
+) ==
+sizeof(unsigned char)
+, ""
+);
+_Static_assert(sizeof
+#embed
+, ""
+);
+_Static_assert(sizeof(
+#embed // expected-warning {{left operand of comma operator has no
effect}}
+) ==
+sizeof(unsigned char)
+, ""
+);
+
+#ifdef __cplusplus
+template
+void j() {
+ static_assert(First == 'j', "");
+ static_assert(Second == 'k', "");
+}
+#endif
+
+void do_stuff() {
+ f(
+#embed
+ );
+ g(
+#embed
+ );
+ h(
+#embed
+ );
+ int r = i();
+ (void)r;
+#ifdef __cplusplus
+ j<
+#embed
+ >(
+#embed
+ );
+#endif
+}
+
+// Ensure that we don't accidentally allow you to initialize an unsigned char *
+// from embedded data; the data is modeled as a string literal internally, but
+// is not actually a string literal.
+const unsigned char *ptr =
+#embed // expected-warning {{left operand of comma operator has no
effect}}
+; // c-error@-2 {{incompatible integer to pointer conversion initializing
'const unsigned char *' with an expression of type 'unsigned char'}} \
+ cxx-error@-2 {{cannot initialize a variable of type 'const unsigned char
*' with an rvalue of type 'unsigned char'}}
+
+// However, there are some cases where this is fine and should work.
+const unsigned char *null_ptr_1 =
+#embed if_empty(0)
+;
+
+const unsigned char *null_ptr_2 =
+#embed
+;
+
+const unsigned char *null_ptr_3 = {
+#embed
+};
+
+#define FILE_NAME
+#define LIMIT 1
+#define OFFSET 0
+#define EMPTY_SUFFIX suffix()
+
+constexpr unsigned char ch =
+#embed FILE_NAME limit(LIMIT) clang::offset(OFFSET) EMPTY_SUFFIX
+;
+static_assert(ch == 0);
AaronBallman wrote:
> I have a prototype of injecting tokens that helps. It also removes all the
> "whack a mole" around template arguments. The only downside it is now yields
> int instead of unsigned char, but I guess it is fine?
Nice! Yes, it's fine to yield an `int`; that's how the feature is defined to
behave in C and we need the semantics to be the same in C and C++.
> Should I push it to this PR or it makes sense to land this first and make a
> separate PR? NOTE: I'm on vacation next week, so I will not be available.
IMO, it would be easier for reviewers to land the current changes and then push
fixes and improvements separately. This patch is already really hard to review
due to size. What do folks think about landing the changes as-is today/tomorrow
and then doing follow-up work once @Fznamznon is back from vacation?
https://github.com/llvm/llvm-project/pull/95802
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang] Fix parsing of reversible type traits in template arguments (PR #95969)
@@ -141,3 +141,15 @@ namespace r360308_regression {
return a == b;
}
}
+
+namespace GH95598 {
+template
+struct __is_pointer {};
+// expected-warning@-1 {{keyword '__is_pointer' will be made available as an
identifier for the remainder of the translation unit}}
AaronBallman wrote:
This diagnostic is very confusing because it implies the name is only available
as an identifier when in reality it's available as *either* an identifier or a
keyword. This seems to be the original functionality though:
https://godbolt.org/z/WzTs4T31j (based on the changes in
https://github.com/llvm/llvm-project/commit/47642d2b7ea175a6c0d80bf14354246ca20af342
which added this diagnostic).
So I think your changes are aligned with the original intent of the diagnostic,
but I've CCed @zygoloid and @rnk just in case others from this era recall
differently.
https://github.com/llvm/llvm-project/pull/95969
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] Reland [clang][Sema, Lex, Parse] Preprocessor embed in C and C++ (PR #95802)
@@ -0,0 +1,98 @@
+// RUN: %clang_cc1 %s -fsyntax-only --embed-dir=%S/Inputs -verify=expected,cxx
-Wno-c23-extensions
+// RUN: %clang_cc1 -x c -std=c23 %s -fsyntax-only --embed-dir=%S/Inputs
-verify=expected,c
+#embed
+;
+
+void f (unsigned char x) { (void)x;}
+void g () {}
+void h (unsigned char x, int y) {(void)x; (void)y;}
+int i () {
+ return
+#embed
+ ;
+}
+
+_Static_assert(
+#embed suffix(,)
+""
+);
+_Static_assert(
+#embed
+, ""
+);
+_Static_assert(sizeof(
+#embed
+) ==
+sizeof(unsigned char)
+, ""
+);
+_Static_assert(sizeof
+#embed
+, ""
+);
+_Static_assert(sizeof(
+#embed // expected-warning {{left operand of comma operator has no
effect}}
+) ==
+sizeof(unsigned char)
+, ""
+);
+
+#ifdef __cplusplus
+template
+void j() {
+ static_assert(First == 'j', "");
+ static_assert(Second == 'k', "");
+}
+#endif
+
+void do_stuff() {
+ f(
+#embed
+ );
+ g(
+#embed
+ );
+ h(
+#embed
+ );
+ int r = i();
+ (void)r;
+#ifdef __cplusplus
+ j<
+#embed
+ >(
+#embed
+ );
+#endif
+}
+
+// Ensure that we don't accidentally allow you to initialize an unsigned char *
+// from embedded data; the data is modeled as a string literal internally, but
+// is not actually a string literal.
+const unsigned char *ptr =
+#embed // expected-warning {{left operand of comma operator has no
effect}}
+; // c-error@-2 {{incompatible integer to pointer conversion initializing
'const unsigned char *' with an expression of type 'unsigned char'}} \
+ cxx-error@-2 {{cannot initialize a variable of type 'const unsigned char
*' with an rvalue of type 'unsigned char'}}
+
+// However, there are some cases where this is fine and should work.
+const unsigned char *null_ptr_1 =
+#embed if_empty(0)
+;
+
+const unsigned char *null_ptr_2 =
+#embed
+;
+
+const unsigned char *null_ptr_3 = {
+#embed
+};
+
+#define FILE_NAME
+#define LIMIT 1
+#define OFFSET 0
+#define EMPTY_SUFFIX suffix()
+
+constexpr unsigned char ch =
+#embed FILE_NAME limit(LIMIT) clang::offset(OFFSET) EMPTY_SUFFIX
+;
+static_assert(ch == 0);
AaronBallman wrote:
Because embed produces tokens from the preprocessor, the first example should
be the same as:
```
void f(float x, char y, char z);
void g() { f((float)
1, 2, 3
);
}
```
which should be accepted (the cast applies to the first argument). You can run
into the same with something like:
```
void f(float x, char y, char z);
void g() {
f(
#embed "three_character_file" prefix((float))
);
}
```
https://github.com/llvm/llvm-project/pull/95802
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang][Interp] Merge ByteCodeExprGen and ByteCodeStmtGen (PR #83683)
Timm =?utf-8?q?B=C3=A4der?= , Timm =?utf-8?q?B=C3=A4der?= Message-ID: In-Reply-To: https://github.com/AaronBallman approved this pull request. LGTM https://github.com/llvm/llvm-project/pull/83683 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang] fix the unexpected controlflow in `ParseTentative.cpp` (PR #95917)
https://github.com/AaronBallman commented: Thank you for working on this! I was trying to devise a test case that would exercise the issue... and I think I've convinced myself this entire function is dead code. It only seems to be possible to reach in C++ mode, but `ident` is annotated as a typename before getting into a code path that would lead here. I removed the code entirely and ran the test suite and no tests failed. @rjmccall -- do you have ideas on how we can trigger the issue here or do you think this code can be removed? https://github.com/llvm/llvm-project/pull/95917 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang] fix the unexpected controlflow in `ParseTentative.cpp` (PR #95917)
https://github.com/AaronBallman edited https://github.com/llvm/llvm-project/pull/95917 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Bounds-Safety] Add sized_by, counted_by_or_null & sized_by_or_null (PR #93231)
https://github.com/AaronBallman approved this pull request. Continues to LGTM, @delcypher are you happy with the changes? https://github.com/llvm/llvm-project/pull/93231 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [BoundsSafety] Add `-fexperimental-bounds-safety` CC1 and language option and use it to tweak `counted_by`'s semantics (PR #92623)
AaronBallman wrote: > To your point about proliferation of flags. `-fexperimental-bounds-safety` > **is the CC1 flag** that guard the `-fbounds-safety` feature in our internal > Clang (modulo the name, we don't have the `experimental-` prefix internally). > It will **need to exist** as we continue upstream more of our implementation > that depends on this flag. Okay, let me make sure I'm on the same page -- what we've been calling `-fbounds-safety` but never actually exposed as a CC1 or driver option is actually going to be exposed under the name `-fexperimental-bounds-safety` as a CC1 option? So there's not going to be two flags for users to have to distinguish between? https://github.com/llvm/llvm-project/pull/92623 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang][Interp] Implement dynamic memory allocation handling (PR #70306)
@@ -2544,6 +2544,85 @@ bool
ByteCodeExprGen::VisitCXXInheritedCtorInitExpr(
return this->emitCall(F, 0, E);
}
+template
+bool ByteCodeExprGen::VisitCXXNewExpr(const CXXNewExpr *E) {
+ assert(classifyPrim(E->getType()) == PT_Ptr);
+ const Expr *Init = E->getInitializer();
+ QualType ElementType = E->getAllocatedType();
+ std::optional ElemT = classify(ElementType);
+
+ const Descriptor *Desc;
+ if (ElemT) {
+if (E->isArray())
+ Desc = nullptr; // We're not going to use it in this case.
+else
+ Desc = P.createDescriptor(E, *ElemT, Descriptor::InlineDescMD,
+/*IsConst=*/false, /*IsTemporary=*/false,
+/*IsMutable=*/false);
+ } else {
+Desc = P.createDescriptor(
+E, ElementType.getTypePtr(),
+E->isArray() ? std::nullopt : Descriptor::InlineDescMD,
+/*IsConst=*/false, /*IsTemporary=*/false, /*IsMutable=*/false, Init);
+ }
+
+ if (E->isArray()) {
+std::optional ArraySizeExpr = E->getArraySize();
+if (!ArraySizeExpr)
+ return false;
+assert(ArraySizeExpr);
AaronBallman wrote:
The assert doesn't seem too useful given the immediately preceding line.
https://github.com/llvm/llvm-project/pull/70306
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang][Interp] Implement dynamic memory allocation handling (PR #70306)
@@ -2544,6 +2544,85 @@ bool
ByteCodeExprGen::VisitCXXInheritedCtorInitExpr(
return this->emitCall(F, 0, E);
}
+template
+bool ByteCodeExprGen::VisitCXXNewExpr(const CXXNewExpr *E) {
+ assert(classifyPrim(E->getType()) == PT_Ptr);
AaronBallman wrote:
I don't think this handles placement new correctly; that should probably have
some FIXME comments + tests so we know to come back to it.
https://github.com/llvm/llvm-project/pull/70306
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang][Interp] Implement dynamic memory allocation handling (PR #70306)
@@ -2544,6 +2544,85 @@ bool
ByteCodeExprGen::VisitCXXInheritedCtorInitExpr(
return this->emitCall(F, 0, E);
}
+template
+bool ByteCodeExprGen::VisitCXXNewExpr(const CXXNewExpr *E) {
+ assert(classifyPrim(E->getType()) == PT_Ptr);
+ const Expr *Init = E->getInitializer();
+ QualType ElementType = E->getAllocatedType();
+ std::optional ElemT = classify(ElementType);
+
+ const Descriptor *Desc;
+ if (ElemT) {
+if (E->isArray())
+ Desc = nullptr; // We're not going to use it in this case.
+else
+ Desc = P.createDescriptor(E, *ElemT, Descriptor::InlineDescMD,
+/*IsConst=*/false, /*IsTemporary=*/false,
+/*IsMutable=*/false);
+ } else {
+Desc = P.createDescriptor(
+E, ElementType.getTypePtr(),
+E->isArray() ? std::nullopt : Descriptor::InlineDescMD,
+/*IsConst=*/false, /*IsTemporary=*/false, /*IsMutable=*/false, Init);
+ }
+
+ if (E->isArray()) {
+std::optional ArraySizeExpr = E->getArraySize();
+if (!ArraySizeExpr)
AaronBallman wrote:
What about a boundless array with an initializer:
https://godbolt.org/z/W36KzrGPq
https://github.com/llvm/llvm-project/pull/70306
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang][Interp] Implement dynamic memory allocation handling (PR #70306)
@@ -2544,6 +2544,85 @@ bool
ByteCodeExprGen::VisitCXXInheritedCtorInitExpr(
return this->emitCall(F, 0, E);
}
+template
+bool ByteCodeExprGen::VisitCXXNewExpr(const CXXNewExpr *E) {
+ assert(classifyPrim(E->getType()) == PT_Ptr);
+ const Expr *Init = E->getInitializer();
+ QualType ElementType = E->getAllocatedType();
+ std::optional ElemT = classify(ElementType);
+
+ const Descriptor *Desc;
+ if (ElemT) {
+if (E->isArray())
+ Desc = nullptr; // We're not going to use it in this case.
+else
+ Desc = P.createDescriptor(E, *ElemT, Descriptor::InlineDescMD,
+/*IsConst=*/false, /*IsTemporary=*/false,
+/*IsMutable=*/false);
+ } else {
+Desc = P.createDescriptor(
+E, ElementType.getTypePtr(),
+E->isArray() ? std::nullopt : Descriptor::InlineDescMD,
+/*IsConst=*/false, /*IsTemporary=*/false, /*IsMutable=*/false, Init);
+ }
+
+ if (E->isArray()) {
+std::optional ArraySizeExpr = E->getArraySize();
+if (!ArraySizeExpr)
+ return false;
+assert(ArraySizeExpr);
+PrimType SizeT = classifyPrim((*ArraySizeExpr)->getType());
+
+if (!this->visit(*ArraySizeExpr))
+ return false;
+
+if (ElemT) {
+ // N primitive elements.
+ if (!this->emitAllocN(SizeT, *ElemT, E, E))
+return false;
+} else {
+ // N Composite elements.
+ if (!this->emitAllocCN(SizeT, Desc, E))
+return false;
+}
+
AaronBallman wrote:
What about initializing the array elements: https://godbolt.org/z/objfW7fTc
https://github.com/llvm/llvm-project/pull/70306
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang][Interp] Implement dynamic memory allocation handling (PR #70306)
@@ -0,0 +1,119 @@
+//== DynamicAllocator.cpp - Dynamic allocations --*- C++
-*-==//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "DynamicAllocator.h"
+#include "InterpBlock.h"
+#include "InterpState.h"
+
+using namespace clang;
+using namespace clang::interp;
+
+DynamicAllocator::~DynamicAllocator() { cleanup(); }
+
+void DynamicAllocator::cleanup() {
+ // Invoke destructors of all the blocks and as a last restort,
+ // reset all the pointers pointing to them to null pointees.
+ // This should never show up in diagnostics, but it's necessary
+ // for us to not cause use-after-free problems.
+ for (auto : AllocationSites) {
+auto = Iter.second;
+for (auto : AllocSite.Allocations) {
+ Block *B = reinterpret_cast(Alloc.Memory.get());
+ B->invokeDtor();
+ if (B->hasPointers()) {
+while (B->Pointers) {
+ Pointer *Next = B->Pointers->Next;
+ B->Pointers->PointeeStorage.BS.Pointee = nullptr;
+ B->Pointers = Next;
+}
+B->Pointers = nullptr;
+ }
+}
+ }
+
+ AllocationSites.clear();
+}
+
+Block *DynamicAllocator::allocate(const Expr *Source, PrimType T,
+ size_t NumElements) {
+ assert(NumElements > 0);
+ // Create a new descriptor for an array of the specified size and
+ // element type.
+ const Descriptor *D = allocateDescriptor(
+ Source, T, Descriptor::InlineDescMD, NumElements, /*IsConst=*/false,
+ /*IsTemporary=*/false, /*IsMutable=*/false);
+ return allocate(D);
+}
+
+Block *DynamicAllocator::allocate(const Descriptor *ElementDesc,
+ size_t NumElements) {
+ assert(NumElements > 0);
+ // Create a new descriptor for an array of the specified size and
+ // element type.
+ const Descriptor *D = allocateDescriptor(
+ ElementDesc->asExpr(), ElementDesc, Descriptor::InlineDescMD,
NumElements,
+ /*IsConst=*/false, /*IsTemporary=*/false, /*IsMutable=*/false);
+ return allocate(D);
+}
+
+Block *DynamicAllocator::allocate(const Descriptor *D) {
+ assert(D->asExpr());
+
+ auto Memory =
+ std::make_unique(sizeof(Block) + D->getAllocSize());
+ auto *B = new (Memory.get()) Block(D, /*isStatic=*/false);
+ B->invokeCtor();
+
+ InlineDescriptor *ID = reinterpret_cast(B->rawData());
+ ID->Desc = D;
+ ID->IsActive = true;
+ ID->Offset = sizeof(InlineDescriptor);
+ ID->IsBase = false;
+ ID->IsFieldMutable = false;
+ ID->IsConst = false;
+ ID->IsInitialized = false;
+ assert(ID->Desc);
+
+ B->IsDynamic = true;
+
+ if (auto It = AllocationSites.find(D->asExpr()); It != AllocationSites.end())
+It->second.Allocations.emplace_back(std::move(Memory));
+ else
+AllocationSites.insert(
+{D->asExpr(), AllocationSite(std::move(Memory), D->isArray())});
+ return B;
+}
+
+bool DynamicAllocator::deallocate(const Expr *Source,
+ const Block *BlockToDelete, InterpState ) {
+ auto It = AllocationSites.find(Source);
+ if (It == AllocationSites.end())
+return false;
+
+ auto = It->second;
+ assert(Site.size() > 0);
+
+ // Find the Block to delete.
+ auto AllocIt = llvm::find_if(Site.Allocations, [&](const Allocation ) {
+const Block *B = reinterpret_cast(A.Memory.get());
+return BlockToDelete == B;
+ });
+
+ assert(AllocIt != Site.Allocations.end());
+
+ Block *B = reinterpret_cast(AllocIt->Memory.get());
+ B->invokeDtor();
+
+ S.deallocate(B);
+ Site.Allocations.erase(AllocIt);
+
+ if (Site.size() == 0)
AaronBallman wrote:
Above we assert `Site.size() > 0` so how do we ever hit this?
https://github.com/llvm/llvm-project/pull/70306
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang] Emit bad shift warnings (PR #70307)
@@ -277,7 +277,9 @@ void dr258(void) {
void dr261(void) {
/* This is still an integer constant expression despite the overflow. */
enum e1 {
-ex1 = __INT_MAX__ + 1 /* expected-warning {{overflow in expression;
result is -2'147'483'648 with type 'int'}} */
+ex1 = __INT_MAX__ + 1 /* expected-warning {{overflow in expression;
result is -2'147'483'648 with type 'int'}}
+ c89only-error {{expression is not an integer
constant expression}}
AaronBallman wrote:
Same question here as to why this is an error in C89.
https://github.com/llvm/llvm-project/pull/70307
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang] Emit bad shift warnings (PR #70307)
@@ -430,7 +430,8 @@ void dr081(void) {
/* Demonstrate that we don't crash when left shifting a signed value; that's
* implementation defined behavior.
*/
- _Static_assert(-1 << 1 == -2, "fail"); /* Didn't shift a zero into the "sign
bit". */
+ _Static_assert(-1 << 1 == -2, "fail"); /* c89only-error {{static assertion
expression is not an integral constant expression}}
AaronBallman wrote:
Something seems wrong here -- why is this an error only in C89 mode? This
should be pedantically diagnosed as a warning, not an error (in all C language
modes).
https://github.com/llvm/llvm-project/pull/70307
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang][ThreadSafety] Warn when constructor is trylock (PR #95290)
@@ -614,9 +619,23 @@ static bool checkTryLockFunAttrCommon(Sema , Decl *D,
const ParsedAttr ,
return false;
}
- // check that all arguments are lockable objects
+ // Check that all remaining arguments are lockable objects.
checkAttrArgsAreCapabilityObjs(S, D, AL, Args, 1);
+ // Check that the attribute is applied to a function.
+ if (!D->isFunctionOrFunctionTemplate()) {
+return false;
+ }
+ // Check that the function returns a boolean, integer, or pointer.
+ QualType ReturnType = D->getAsFunction()->getReturnType();
+ if (!ReturnType->isBooleanType() && !ReturnType->isIntegerType() &&
+ !ReturnType->isPointerType()) {
+S.Diag(AL.getLoc(), diag::err_attribute_wrong_decl_type)
+<< AL << AL.isRegularKeywordAttribute()
+<< ExpectedFunctionReturningBoolIntegerOrPointer;
+return false;
+ }
+
return true;
}
AaronBallman wrote:
Should we flip the logic here so we're looking for:
```
if (ReturnType->isBooleanType() || ReturnType->isIntegerType()...)
return true;
return !S.Diag(...);
```
https://github.com/llvm/llvm-project/pull/95290
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang][ThreadSafety] Warn when constructor is trylock (PR #95290)
@@ -614,9 +619,23 @@ static bool checkTryLockFunAttrCommon(Sema , Decl *D,
const ParsedAttr ,
return false;
}
- // check that all arguments are lockable objects
+ // Check that all remaining arguments are lockable objects.
checkAttrArgsAreCapabilityObjs(S, D, AL, Args, 1);
+ // Check that the attribute is applied to a function.
+ if (!D->isFunctionOrFunctionTemplate()) {
AaronBallman wrote:
Is this check needed? The definition in Attr.td already specifies a subject
list including functions, so I believe this is already handled automatically.
https://github.com/llvm/llvm-project/pull/95290
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang][ThreadSafety] Warn when constructor is trylock (PR #95290)
AaronBallman wrote: > * A handful of functions in the parsing tests return `void` and yet are > annotated as trylock functions. I don't believe this is a valid use case. > What does `EXCLUSIVE_TRYLOCK_FUNCTION` mean when it's impossible to return a > value? I think the solution is to just change `void` to `bool` for trylock > functions in tests. Agreed > * This next failure is tricker... I was really surprised to see a trylock > method that returns a pointer! Confusingly, the "success" parameter to the > attribute is `1`. I think the semantics work out so that returning a > non-`nullptr` value indicates successful mutex acquisition. Oof, that's an odd one, but I can see the logic behind supporting it. I think it would be good for us to call out support for this explicitly in the documentation. > I'm not quite sure what to do here. Maybe we should be lenient and only > enforce that the return type is boolean, integer, or pointer? We definitely need to support integer return types because of how often integers or enumerations are used to indicate errors. I think we should continue to support the pointer behavior given that it works already today. https://github.com/llvm/llvm-project/pull/95290 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang] Fix immediate escalation in templated entities (PR #95233)
https://github.com/AaronBallman edited https://github.com/llvm/llvm-project/pull/95233 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang] Fix immediate escalation in templated entities (PR #95233)
https://github.com/AaronBallman approved this pull request. LGTM! https://github.com/llvm/llvm-project/pull/95233 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang] Remove update_options_td_flags.py (PR #95909)
https://github.com/AaronBallman approved this pull request. LGTM! https://github.com/llvm/llvm-project/pull/95909 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang] Remove update_options_td_flags.py (PR #95909)
https://github.com/AaronBallman edited https://github.com/llvm/llvm-project/pull/95909 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [lldb] [clang][AST] fix ast-print of extern with >=2 declarators, fixed (PR #93913)
@@ -2380,7 +2380,7 @@ FunctionDecl *Sema::CreateBuiltin(IdentifierInfo *II, QualType Type, } FunctionDecl *New = FunctionDecl::Create(Context, Parent, Loc, Loc, II, Type, - /*TInfo=*/nullptr, SC_Extern, + /*TInfo=*/nullptr, SC_None, AaronBallman wrote: I think I've come around to being okay with these changes, thank you! https://github.com/llvm/llvm-project/pull/93913 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [lldb] [clang][AST] fix ast-print of extern with >=2 declarators, fixed (PR #93913)
https://github.com/AaronBallman edited https://github.com/llvm/llvm-project/pull/93913 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [lldb] [clang][AST] fix ast-print of extern with >=2 declarators, fixed (PR #93913)
@@ -576,13 +576,18 @@ template static bool
isFirstInExternCContext(T *D) {
return First->isInExternCContext();
}
-static bool isSingleLineLanguageLinkage(const Decl ) {
- if (const auto *SD = dyn_cast(D.getDeclContext()))
-if (!SD->hasBraces())
- return true;
+static bool isUnbracedLanguageLinkage(const DeclContext *DC) {
+ if (!DC)
+return false;
+ if (const auto *SD = dyn_cast(DC))
+return !SD->hasBraces();
return false;
}
AaronBallman wrote:
```suggestion
if (const auto *SD = dyn_cast_if_present(DC))
return !SD->hasBraces();
return false;
}
```
Sorry for not noticing this earlier, but we can simplify even further this way.
https://github.com/llvm/llvm-project/pull/93913
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [lldb] [clang][AST] fix ast-print of extern with >=2 declarators, fixed (PR #93913)
https://github.com/AaronBallman approved this pull request. LGTM with another small improvement that could be made. https://github.com/llvm/llvm-project/pull/93913 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [lldb] [clang][AST] fix ast-print of extern with >=2 declarators, fixed (PR #93913)
@@ -2380,7 +2380,7 @@ FunctionDecl *Sema::CreateBuiltin(IdentifierInfo *II, QualType Type, } FunctionDecl *New = FunctionDecl::Create(Context, Parent, Loc, Loc, II, Type, - /*TInfo=*/nullptr, SC_Extern, + /*TInfo=*/nullptr, SC_None, AaronBallman wrote: Ah, you're right, it's only *objects* declared at local scope that have no linkage (the following paragraph), not *functions*. https://github.com/llvm/llvm-project/pull/93913 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [lldb] [clang][AST] fix ast-print of extern with >=2 declarators, fixed (PR #93913)
@@ -2380,7 +2380,7 @@ FunctionDecl *Sema::CreateBuiltin(IdentifierInfo *II, QualType Type, } FunctionDecl *New = FunctionDecl::Create(Context, Parent, Loc, Loc, II, Type, - /*TInfo=*/nullptr, SC_Extern, + /*TInfo=*/nullptr, SC_None, AaronBallman wrote: > You are right, I also paid attention to that issue. However, when a storage > class specifier is omitted for a function, it's storage class is implicitly > supposed to be extern. Thus, it's fine. That's not actually correct -- the declaration of a function at block scope should definitely *not* be extern, it should have no linkage: https://godbolt.org/z/81fMaPaTq > Furthermore, the meaning of this field according to the documentation > comments is not for the actual storage duration or linkage, but for the > storage-class specifier as present in the source code. Since builtins aren't > really present in the source code, it seems further reasonable to omit a > specifier. Builtins should behave as-if they were declared in a header file that was included in the TU, and so they typically would be marked as `extern`. https://github.com/llvm/llvm-project/pull/93913 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [lldb] [clang][AST] fix ast-print of extern with >=2 declarators, fixed (PR #93913)
@@ -2380,7 +2380,7 @@ FunctionDecl *Sema::CreateBuiltin(IdentifierInfo *II, QualType Type, } FunctionDecl *New = FunctionDecl::Create(Context, Parent, Loc, Loc, II, Type, - /*TInfo=*/nullptr, SC_Extern, + /*TInfo=*/nullptr, SC_None, AaronBallman wrote: This change looks suspicious to me -- this is creating a builtin function, which should be modeled as an extern. In C++, you seem to be relying on the language linkage being sufficient for that, but C has no notion of language linkage and so I worry that the declaration for the builtin will be incorrectly handled in C. https://github.com/llvm/llvm-project/pull/93913 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [lldb] [clang][AST] fix ast-print of extern with >=2 declarators, fixed (PR #93913)
@@ -6286,7 +6286,7 @@ static FunctionDecl *rewriteBuiltinFunctionDecl(Sema *Sema, ASTContext , FunctionDecl *OverloadDecl = FunctionDecl::Create( Context, Parent, FDecl->getLocation(), FDecl->getLocation(), FDecl->getIdentifier(), OverloadTy, - /*TInfo=*/nullptr, SC_Extern, Sema->getCurFPFeatures().isFPConstrained(), + /*TInfo=*/nullptr, SC_None, Sema->getCurFPFeatures().isFPConstrained(), AaronBallman wrote: Same concern here as above. https://github.com/llvm/llvm-project/pull/93913 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [lldb] [clang][AST] fix ast-print of extern with >=2 declarators, fixed (PR #93913)
@@ -576,13 +576,19 @@ template static bool
isFirstInExternCContext(T *D) {
return First->isInExternCContext();
}
-static bool isSingleLineLanguageLinkage(const Decl ) {
- if (const auto *SD = dyn_cast(D.getDeclContext()))
+static bool isUnbracedLanguageLinkage(const DeclContext *DC) {
+ if (!DC)
+return false;
+ if (const auto *SD = dyn_cast(DC))
if (!SD->hasBraces())
return true;
AaronBallman wrote:
```suggestion
return !SD->hasBraces();
```
https://github.com/llvm/llvm-project/pull/93913
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] [llvm] [mlir] [clang][lldb][mlir] Fix some identical sub-expressions warnings (NFC) (PR #95715)
@@ -96,7 +96,7 @@ bool areStatementsIdentical(const Stmt *FirstStmt, const Stmt *SecondStmt, if (FirstStmt == SecondStmt) return true; - if (FirstStmt->getStmtClass() != FirstStmt->getStmtClass()) + if (FirstStmt->getStmtClass() != SecondStmt->getStmtClass()) AaronBallman wrote: This looks like a functional change, it would be good to have a test for it. https://github.com/llvm/llvm-project/pull/95715 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] [llvm] [mlir] [clang][lldb][mlir] Fix some identical sub-expressions warnings (NFC) (PR #95715)
@@ -4368,7 +4368,7 @@ bool
Sema::DiagRedefinedPlaceholderFieldDecl(SourceLocation Loc,
Diag(Loc, diag::err_using_placeholder_variable) << Name;
for (DeclContextLookupResult::iterator It = Found; It != Result.end(); It++)
{
const NamedDecl *ND = *It;
-if (ND->getDeclContext() != ND->getDeclContext())
+if (ND->getDeclContext() != ClassDecl->getDeclContext())
AaronBallman wrote:
This looks like a functional change to me; if no tests broke, we should
probably figure out a test to add for this change.
https://github.com/llvm/llvm-project/pull/95715
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] [llvm] [mlir] [clang][lldb][mlir] Fix some identical sub-expressions warnings (NFC) (PR #95715)
@@ -430,11 +430,10 @@ class HTMLLogger : public Logger {
AST.getSourceManager(), AST.getLangOpts());
if (EltRange.isInvalid())
continue;
- if (EltRange.getBegin() < Range.getBegin() ||
- EltRange.getEnd() >= Range.getEnd() ||
- EltRange.getEnd() < Range.getBegin() ||
- EltRange.getEnd() >= Range.getEnd())
+ if (EltRange.getEnd() <= Range.getBegin() ||
AaronBallman wrote:
This looks like it misses the case where `EltRange.getBegin() <
Range.getBegin()`; shouldn't this be:
```
if (EltRange.getBegin() < Range.getBegin() ||
EltRange.getEnd() >= Range.getEnd())
```
https://github.com/llvm/llvm-project/pull/95715
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] [llvm] [mlir] [clang][lldb][mlir] Fix some identical sub-expressions warnings (NFC) (PR #95715)
AaronBallman wrote: Note, this fixes #95670 https://github.com/llvm/llvm-project/pull/95715 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang] skip alignment checks on incomplete types to avoid an assertion failure while parsing lambda used as default argument (PR #94542)
https://github.com/AaronBallman edited https://github.com/llvm/llvm-project/pull/94542 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang] skip alignment checks on incomplete types to avoid an assertion failure while parsing lambda used as default argument (PR #94542)
https://github.com/AaronBallman approved this pull request. LGTM https://github.com/llvm/llvm-project/pull/94542 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] [ubsan] Display correct runtime messages for negative _BitInt (PR #93612)
@@ -3318,6 +3353,20 @@ llvm::Constant
*CodeGenFunction::EmitCheckTypeDescriptor(QualType T) {
DiagnosticsEngine::ak_qualtype, (intptr_t)T.getAsOpaquePtr(),
StringRef(),
StringRef(), std::nullopt, Buffer, std::nullopt);
+ if (IsBitInt) {
+// The Structure is: 0 to end the string, 32 bit unsigned integer in target
+// endianness, zero.
+char s[6] = {'\0', '\0', '\0', '\0', '\0', '\0'};
AaronBallman wrote:
```suggestion
char S[6] = {'\0', '\0', '\0', '\0', '\0', '\0'};
```
For usual naming conventions.
https://github.com/llvm/llvm-project/pull/93612
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] [ubsan] Display correct runtime messages for negative _BitInt (PR #93612)
https://github.com/AaronBallman edited https://github.com/llvm/llvm-project/pull/93612 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] [ubsan] Display correct runtime messages for negative _BitInt (PR #93612)
@@ -3318,6 +3353,20 @@ llvm::Constant
*CodeGenFunction::EmitCheckTypeDescriptor(QualType T) {
DiagnosticsEngine::ak_qualtype, (intptr_t)T.getAsOpaquePtr(),
StringRef(),
StringRef(), std::nullopt, Buffer, std::nullopt);
+ if (IsBitInt) {
+// The Structure is: 0 to end the string, 32 bit unsigned integer in target
+// endianness, zero.
+char s[6] = {'\0', '\0', '\0', '\0', '\0', '\0'};
+const auto *EIT = T->getAs();
AaronBallman wrote:
```suggestion
const auto *EIT = T->castAs();
```
We don't expect it to ever return a null pointer, so we might as well cast
instead.
https://github.com/llvm/llvm-project/pull/93612
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] [ubsan] Display correct runtime messages for negative _BitInt (PR #93612)
https://github.com/AaronBallman commented: The changes seem pretty reasonable to me (aside from a few small nits), but I'd appreciate someone with more compiler-rt knowledge to also sign off on the changes. https://github.com/llvm/llvm-project/pull/93612 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] clang: Relax LangOpts checks when lexing quoted numbers during preprocessing (PR #95798)
https://github.com/AaronBallman commented: The changes should come with a release note in clang/docs/ReleaseNotes.rst so users know about the fix. The changes otherwise look correct, but I'd like to hear from @jansvoboda11 as well (especially in light of the question I raised on the original PR). https://github.com/llvm/llvm-project/pull/95798 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] clang: Relax LangOpts checks when lexing quoted numbers during preprocessing (PR #95798)
https://github.com/AaronBallman edited https://github.com/llvm/llvm-project/pull/95798 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Pass LangOpts from CompilerInstance to DependencyScanningWorker (PR #93753)
AaronBallman wrote: > > > I guess the general question is - is it acceptable to have the Scanner > > > operating in a language standard different than the passed in language > > > mode and different than the compiler language standard? > > > > > > I think that is acceptable. It is kinda hacky, but the lexer and > > preprocessor are largely independent of the language and the standard. When > > they do depend on those settings, taking the union of the features and > > letting the compiler trim it down is still a perfectly sound thing to do. > > You can certainly construct cases where the different lexing rules in > different language modes allow you to detect which language you're in from > within the preprocessor ([1](https://eel.is/c++draft/diff.cpp11.lex) > [2](https://eel.is/c++draft/diff.cpp14.lex#2) > [3](https://eel.is/c++draft/diff.cpp03.lex#1)) or where enabling more > language mode flags may reject valid code. It may be good enough for what the > scanner is trying to do, but I think it's a stretch to say that it's sound. +1; it's definitely not sound to go this approach, though it may work well enough in practice to be worth the tradeoff. That said, I think the behavior of the dependency scanner ignoring the language options used is actually kind of problematic, unless I'm misunderstanding something. This means command line options that impact dependency scanning may fail (for example, the user might enable SYCL or OpenMP on the command line and that may have different dependencies, trigraph support may be important for things like `??=include`, freestanding vs not impacts which preprocessor macros are predefined, etc. How do we handle that sort of stuff, or do we just ignore it? https://github.com/llvm/llvm-project/pull/93753 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
