@@ -304,7 +304,7 @@ getCodeModel(const CodeGenOptions &CodeGenOpts) {
.Case("kernel", llvm::CodeModel::Kernel)
.Case("medium", llvm::CodeModel::Medium)
.Case("large", llvm::CodeModel::Large)
-
AaronBallman wrote:
> > > But the token kind we have is `identifier` and not one of the keywords,
> > > so we can't do the more trivial integer comparisons.
> >
> >
> > Can we precompute a list/map/whatever of all identifiers that are keywords
> > in C++ but not in C and then do pointer compa
https://github.com/AaronBallman updated
https://github.com/llvm/llvm-project/pull/137234
>From 56a3f3cd282e9bd5ef9014e4125380e0d9685121 Mon Sep 17 00:00:00 2001
From: Aaron Ballman
Date: Thu, 24 Apr 2025 14:17:42 -0400
Subject: [PATCH 01/11] [C] Diagnose use of C++ keywords in C
This add
Mon Sep 17 00:00:00 2001
From: Aaron Ballman
Date: Fri, 25 Apr 2025 08:49:35 -0400
Subject: [PATCH] Fix crash with -ast-dump=json
When given an invalid Objective-C extension, Clang would crash when
trying to emit the mangled name of the method to the JSON dump output.
Fixes #137320
---
clang/d
https://github.com/AaronBallman closed
https://github.com/llvm/llvm-project/pull/137166
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/AaronBallman updated
https://github.com/llvm/llvm-project/pull/137234
>From 56a3f3cd282e9bd5ef9014e4125380e0d9685121 Mon Sep 17 00:00:00 2001
From: Aaron Ballman
Date: Thu, 24 Apr 2025 14:17:42 -0400
Subject: [PATCH 01/10] [C] Diagnose use of C++ keywords in C
This add
https://github.com/AaronBallman updated
https://github.com/llvm/llvm-project/pull/137234
>From 56a3f3cd282e9bd5ef9014e4125380e0d9685121 Mon Sep 17 00:00:00 2001
From: Aaron Ballman
Date: Thu, 24 Apr 2025 14:17:42 -0400
Subject: [PATCH 1/9] [C] Diagnose use of C++ keywords in C
This adds a
AaronBallman wrote:
> > But the token kind we have is `identifier` and not one of the keywords, so
> > we can't do the more trivial integer comparisons.
>
> Can we precompute a list/map/whatever of all identifiers that are keywords in
> C++ but not in C and then do pointer comparisons on the `
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/137234
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/AaronBallman updated
https://github.com/llvm/llvm-project/pull/137234
>From 56a3f3cd282e9bd5ef9014e4125380e0d9685121 Mon Sep 17 00:00:00 2001
From: Aaron Ballman
Date: Thu, 24 Apr 2025 14:17:42 -0400
Subject: [PATCH 1/8] [C] Diagnose use of C++ keywords in C
This adds a
AaronBallman wrote:
> What about `and`, `or`, and friends (which I think are only keywords in C if
> you include a certain header irrc).
Good call, I'll add those.
https://github.com/llvm/llvm-project/pull/137234
___
cfe-commits mailing list
cfe-comm
@@ -0,0 +1,213 @@
+// RUN: %clang_cc1 -fsyntax-only -verify -Widentifier-is-c++-keyword %s
+// RUN: %clang_cc1 -fsyntax-only -verify -Wc++-compat %s
+// RUN: %clang_cc1 -fsyntax-only -verify=good %s
+// RUN: %clang_cc1 -fsyntax-only -verify=cxx -x c++ -std=c++2c %s
+// good-no-dia
AaronBallman wrote:
This change appears to have introduced a regression:
https://github.com/llvm/llvm-project/issues/114815 with fairly trivial code:
```
int decltype;
```
Any chance you can investigate @sdkrystian?
https://github.com/llvm/llvm-project/pull/96364
___
AaronBallman wrote:
Alas, I think this PR may be a non-starter due to performance:
https://llvm-compile-time-tracker.com/?config=Overview&stat=wall-time&remote=AaronBallman:
```
C 56a3f3cd28 8.04s (+2.96%) 8.23s (+3.32%) 11.87s (+1.92%)
2.83s (+10.21%) 8.50s
@@ -6496,6 +6496,17 @@ static bool canPerformArrayCopy(const InitializedEntity
&Entity) {
return false;
}
+static const FieldDecl *GetConstField(const RecordDecl *RD) {
AaronBallman wrote:
Ah fair enough, I've added an assert
https://github.com/llvm/llvm-
https://github.com/AaronBallman updated
https://github.com/llvm/llvm-project/pull/137166
>From bb184fc38d13126f244615425cfefe7368ca71b8 Mon Sep 17 00:00:00 2001
From: Aaron Ballman
Date: Wed, 23 Apr 2025 13:40:44 -0400
Subject: [PATCH 1/8] Add -Wdefault-const-init
---
clang/d
@@ -6496,6 +6496,17 @@ static bool canPerformArrayCopy(const InitializedEntity
&Entity) {
return false;
}
+static const FieldDecl *getConstField(const RecordDecl *RD) {
+ for (const FieldDecl *FD : RD->fields()) {
+QualType QT = FD->getType();
+if (QT.isConstQualif
@@ -0,0 +1,55 @@
+// RUN: %clang_cc1 -fsyntax-only -verify=c,unsafe -Wdefault-const-init %s
+// RUN: %clang_cc1 -fsyntax-only -verify=c,unsafe -Wc++-compat %s
+// RUN: %clang_cc1 -fsyntax-only -verify=unsafe %s
+// RUN: %clang_cc1 -fsyntax-only -verify=c -Wdefault-const-init
-Wno
https://github.com/AaronBallman updated
https://github.com/llvm/llvm-project/pull/137166
>From bb184fc38d13126f244615425cfefe7368ca71b8 Mon Sep 17 00:00:00 2001
From: Aaron Ballman
Date: Wed, 23 Apr 2025 13:40:44 -0400
Subject: [PATCH 1/7] Add -Wdefault-const-init
---
clang/d
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/137166
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -6496,6 +6496,17 @@ static bool canPerformArrayCopy(const InitializedEntity
&Entity) {
return false;
}
+static const FieldDecl *GetConstField(const RecordDecl *RD) {
AaronBallman wrote:
No assertion is possible, `CXXRecordDecl` has bases, `RecordDecl` d
AaronBallman wrote:
> Maybe `-Wkeyword-in-c++` or `-Wc++-keyword` would be a more concise name for
> the group?
I'm not tied to the name I picked, so either of these is fine by me. GCC
doesn't split this into its own warning group, so we've got some latitude.
Any strong preferences?
https://
https://github.com/AaronBallman updated
https://github.com/llvm/llvm-project/pull/137234
>From 56a3f3cd282e9bd5ef9014e4125380e0d9685121 Mon Sep 17 00:00:00 2001
From: Aaron Ballman
Date: Thu, 24 Apr 2025 14:17:42 -0400
Subject: [PATCH 1/4] [C] Diagnose use of C++ keywords in C
This adds a
AaronBallman wrote:
Note, I'm running this one through llvm-compile-time-tracker because of the
lookup happening on every identifier. I'm not convinced that the "is this
identifier a keyword in other language modes" code has good performance and
wanted to double-check.
https://github.com/llvm
https://github.com/AaronBallman updated
https://github.com/llvm/llvm-project/pull/137234
>From 56a3f3cd282e9bd5ef9014e4125380e0d9685121 Mon Sep 17 00:00:00 2001
From: Aaron Ballman
Date: Thu, 24 Apr 2025 14:17:42 -0400
Subject: [PATCH 1/3] [C] Diagnose use of C++ keywords in C
This adds a
:00 2001
From: Aaron Ballman
Date: Thu, 24 Apr 2025 14:17:42 -0400
Subject: [PATCH 1/2] [C] Diagnose use of C++ keywords in C
This adds a new diagnostic group, -Widentifier-is-c++-keyword, which is
off by default and grouped under -Wc++-compat. The diagnostic catches
use of C++ keywords in C code.
T
https://github.com/AaronBallman approved this pull request.
LGTM!
https://github.com/llvm/llvm-project/pull/136783
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -3489,6 +3489,11 @@ class CompoundLiteralExpr : public Expr {
/// The int part of the pair stores whether this expr is file scope.
llvm::PointerIntPair TInfoAndScope;
Stmt *Init;
+
+ /// Value of constant literals with static storage duration. Used only for
+ /// con
@@ -6496,6 +6496,17 @@ static bool canPerformArrayCopy(const InitializedEntity
&Entity) {
return false;
}
+static const FieldDecl *GetConstField(const RecordDecl *RD) {
AaronBallman wrote:
C has no base classes, so nope!
https://github.com/llvm/llvm-proje
@@ -139,22 +141,41 @@ class FactEntry : public CapabilityExpr {
bool declared() const { return Source == Declared; }
bool managed() const { return Source == Managed; }
- virtual void
- handleRemovalFromIntersection(const FactSet &FSet, FactManager &FactMan,
-
@@ -8197,6 +8197,16 @@ def err_address_space_qualified_new : Error<
def err_address_space_qualified_delete : Error<
"'delete' cannot delete objects of type %0 in address space '%1'">;
+def note_default_init_const_member : Note<
+ "member %0 declared 'const' here">;
+def war
rom bb184fc38d13126f244615425cfefe7368ca71b8 Mon Sep 17 00:00:00 2001
From: Aaron Ballman
Date: Wed, 23 Apr 2025 13:40:44 -0400
Subject: [PATCH 1/5] Add -Wdefault-const-init
---
clang/docs/ReleaseNotes.rst | 3 ++
clang/include/clang/Basic/DiagnosticGroups.td | 3 +-
.../clang/Ba
@@ -3990,6 +3990,13 @@ def LocksExcluded : InheritableAttr {
let Documentation = [Undocumented];
}
+def ReentrantCapability : InheritableAttr {
+ let Spellings = [Clang<"reentrant_capability">];
+ let Subjects = SubjectList<[Record, TypedefName]>;
+ let Documentation = [U
https://github.com/AaronBallman approved this pull request.
The changes LGTM, so if we don't hear back from the folks we've pinged in the
next few days, I'd say this is safe to land.
https://github.com/llvm/llvm-project/pull/132984
___
cfe-commits mai
@@ -569,7 +569,7 @@
CrossTranslationUnitContext::ASTLoader::loadFromDump(StringRef ASTDumpPath) {
return ASTUnit::LoadFromASTFile(
ASTDumpPath, CI.getPCHContainerOperations()->getRawReader(),
ASTUnit::LoadEverything, Diags, CI.getFileSystemOpts(),
- CI.getHe
AaronBallman wrote:
Thanks! You're right, it may not address the issue we were seeing. Some of our
were also ending up with:
```
==3187048==WARNING: MemorySanitizer: use-of-uninitialized-value
#0 0x1f73c115 in clang::APValue::operator=(clang::APValue&&)
(/netbatch/donb2642835_00/runDir/
https://github.com/AaronBallman updated
https://github.com/llvm/llvm-project/pull/137166
>From bb184fc38d13126f244615425cfefe7368ca71b8 Mon Sep 17 00:00:00 2001
From: Aaron Ballman
Date: Wed, 23 Apr 2025 13:40:44 -0400
Subject: [PATCH 1/6] Add -Wdefault-const-init
---
clang/d
https://github.com/AaronBallman approved this pull request.
LGTM!
https://github.com/llvm/llvm-project/pull/132776
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -48,14 +48,6 @@ if (LLVM_ENABLE_DOXYGEN)
set(bolt_doxygen_qhp_cust_filter_attrs "")
endif()
- option(LLVM_DOXYGEN_SVG
AaronBallman wrote:
Awesome, thanks!
https://github.com/llvm/llvm-project/pull/136843
https://github.com/AaronBallman commented:
I think the changes LG, but please wait for our CMake experts (@petrhosek and
@Ericson2314) to review before landing.
https://github.com/llvm/llvm-project/pull/136843
___
cfe-commits mailing list
cfe-commits@
AaronBallman wrote:
> Hi @AaronBallman ! Again I appreciate your suggestion. I ran into some
> complexities when adding a test. It is precisely that this is a very internal
> API that is giving me some trouble. Since `clang/tools/libclang/CXString.h`
> is not an exposed header, I cannot really
AaronBallman wrote:
Yeah, sorry, I feel I accidentally derailed the conversation by talking about
new types. :-) Are we converging on the idea of using type sugar?
https://github.com/llvm/llvm-project/pull/136542
___
cfe-commits mailing list
cfe-commi
https://github.com/AaronBallman closed
https://github.com/llvm/llvm-project/pull/136855
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/AaronBallman commented:
Where is this new API expected to be used?
https://github.com/llvm/llvm-project/pull/136773
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
AaronBallman wrote:
> LGTM, but how this fares against our stability guarantees for libclang APIs?
> Do we need `clang_File_isEqual2`?
I think this is a bug fix and so it meets our requirements. The ABI is stable,
but we can fix logic bugs.
https://github.com/llvm/llvm-project/pull/135773
___
https://github.com/AaronBallman updated
https://github.com/llvm/llvm-project/pull/136855
>From 73a0a93e22976fd8ffdd5df70c459b648b7dd06d Mon Sep 17 00:00:00 2001
From: Aaron Ballman
Date: Wed, 23 Apr 2025 07:15:42 -0400
Subject: [PATCH 1/3] Diagnose implicit void * casts under -Wc++-com
AaronBallman wrote:
> Something being unspecified in the standard doesn't mean we're unconstrained.
> In this case, it is unspecified because it is allowed to vary between
> platforms, but platforms are required to specify what type `size_t` is, and
> it is well-defined to write code based on
AaronBallman wrote:
> That is not possible, and this is exactly what I'm worried about with all
> this discussion about making `size_t` more "built-in". `size_t` is specified
> to be a typedef of a (platform-dependent) standard integer type, and it needs
> to continue to behave that way; we ca
@@ -48,14 +48,6 @@ if (LLVM_ENABLE_DOXYGEN)
set(bolt_doxygen_qhp_cust_filter_attrs "")
endif()
- option(LLVM_DOXYGEN_SVG
AaronBallman wrote:
Will removing the option be disruptive (particularly to downstreams)? Do we
need a deprecation period before w
AaronBallman wrote:
> > FYI this introduces some overhead:
> > https://llvm-compile-time-tracker.com/compare.php?from=2a9f77f6bd48d757b2d45aadcb6cf76ef4b4ef32&to=71ce9e26aec00e4af27a69ccfab8ca1773ed7018&stat=instructions:u
> > About 0.3% on clang files.
>
> Thank you for the notification! Shoo
https://github.com/AaronBallman approved this pull request.
LGTM, thank you for the fix!
https://github.com/llvm/llvm-project/pull/135773
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commit
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/136836
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -7138,6 +7138,13 @@ def warn_consecutive_comparison : Warning<
"chained comparison 'X %0 Y %1 Z' does not behave the same as a mathematical
expression">,
InGroup, DefaultError;
+def warn_comparison_in_fold_expression
+: Warning<
+ "comparison in a fold exp
https://github.com/AaronBallman approved this pull request.
LGTM with a minor rewording and reformatting of the diagnostic message.
https://github.com/llvm/llvm-project/pull/136836
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.l
Author: Aaron Ballman
Date: 2025-04-23T07:16:44-04:00
New Revision: 500a0cbcbb547e2a54b25162f20808b45af0
URL:
https://github.com/llvm/llvm-project/commit/500a0cbcbb547e2a54b25162f20808b45af0
DIFF:
https://github.com/llvm/llvm-project/commit/500a0cbcbb547e2a54b25162f20808b45af0.diff
https://github.com/AaronBallman closed
https://github.com/llvm/llvm-project/pull/136323
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
AaronBallman wrote:
> @kadircet let's team up tomorrow and poke at what's happening with the
> smaller reproducer to figure out if this is the right fix?
>
> @AaronBallman I was initially concerned that it would be incorrect to
> consider the compound literal expression a full expression even
@@ -265,6 +265,9 @@ related warnings within the method body.
``format_matches`` accepts an example valid format string as its third
argument. For more information, see the Clang attributes documentation.
+- Format string checking now supports the compile-time evaluation of
@@ -6331,26 +6321,79 @@ static StringLiteralCheckType checkFormatStringExpr(
}
}
-return SLCT_NotALiteral;
+// try to constant-evaluate the string
+break;
}
default:
+// try to constant-evaluate the string
+break;
+ }
+
+ const StringLit
@@ -6331,26 +6321,79 @@ static StringLiteralCheckType checkFormatStringExpr(
}
}
-return SLCT_NotALiteral;
+// try to constant-evaluate the string
+break;
}
default:
+// try to constant-evaluate the string
+break;
+ }
+
+ const StringLit
@@ -3,6 +3,11 @@
// RUN: %clang_cc1 -fblocks -fsyntax-only -verify -Wformat-nonliteral -isystem
%S/Inputs -triple=x86_64-unknown-fuchsia %s
// RUN: %clang_cc1 -fblocks -fsyntax-only -verify -Wformat-nonliteral -isystem
%S/Inputs -triple=x86_64-linux-android %s
+// expected-n
https://github.com/AaronBallman closed
https://github.com/llvm/llvm-project/pull/136586
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/AaronBallman approved this pull request.
LGTM!
https://github.com/llvm/llvm-project/pull/136038
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
AaronBallman wrote:
> Another possibility would be to add a new kind of type sugar for these cases
> that has the same canonical type but knows that it should print as `size_t` /
> `ptrdiff_t` etc. That'd allow you to produce an identical AST regardless of
> whether the typedefs are included,
https://github.com/AaronBallman updated
https://github.com/llvm/llvm-project/pull/136323
>From 3beecb29772e13c6a1a41877e5e8cbbfb17a88f2 Mon Sep 17 00:00:00 2001
From: Aaron Ballman
Date: Fri, 18 Apr 2025 12:26:36 -0400
Subject: [PATCH 1/5] Control analysis-based diagnostics with #pra
https://github.com/AaronBallman updated
https://github.com/llvm/llvm-project/pull/136586
>From 49dcc67a3a448a3339c40ffb8b0fe58489e7554a Mon Sep 17 00:00:00 2001
From: Aaron Ballman
Date: Mon, 21 Apr 2025 13:40:19 -0400
Subject: [PATCH 1/2] Reorganize -Winitializer-overrides and
-Wreorder-i
AaronBallman wrote:
Any other changes needed, or are you happy @haoNoQ? @erichkeane @Sirraide want
to re-review given the significant reworking?
https://github.com/llvm/llvm-project/pull/136323
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
h
https://github.com/AaronBallman updated
https://github.com/llvm/llvm-project/pull/136586
>From 49dcc67a3a448a3339c40ffb8b0fe58489e7554a Mon Sep 17 00:00:00 2001
From: Aaron Ballman
Date: Mon, 21 Apr 2025 13:40:19 -0400
Subject: [PATCH 1/2] Reorganize -Winitializer-overrides and
-Wreorder-i
:00 2001
From: Aaron Ballman
Date: Mon, 21 Apr 2025 13:40:19 -0400
Subject: [PATCH] Reorganize -Winitializer-overrides and -Wreorder-init-list
These are both now grouped under -Wc99-designator as they both relate
to the C99 feature as it was introduced into C++20.
Fixes #47037
---
clang/d
AaronBallman wrote:
> @AaronBallman Should this issue ideally be resolved by CFG rather than the
> current AST matcher fix?
I think so. CC @gribozavr @ymand @sgatev for additional opinions
https://github.com/llvm/llvm-project/pull/135573
___
cfe-comm
AaronBallman wrote:
> > I don't think we can do that, at least for C, because that means this code
> > would then be accepted when it shouldn't be, right?
>
> Yeah, I am not sure we can do this now then. It seems odd to allow calls to
> builtins to change their return 'type' (or at least, retu
AaronBallman wrote:
> > > > Thank you for this!
> > > > I'd like to better understand the need for the changes because I have a
> > > > few concerns. One concern is about compile time performance. But also,
> > > > this means downstream consumers of the AST are going to have to react
> > > > b
AaronBallman wrote:
> > > Thank you for this!
> > > I'd like to better understand the need for the changes because I have a
> > > few concerns. One concern is about compile time performance. But also,
> > > this means downstream consumers of the AST are going to have to react
> > > because the
AaronBallman wrote:
> > Thank you for this!
> > I'd like to better understand the need for the changes because I have a few
> > concerns. One concern is about compile time performance. But also, this
> > means downstream consumers of the AST are going to have to react because
> > they used to
@@ -1049,6 +1049,7 @@ Parser::ParseExternalDeclaration(ParsedAttributes &Attrs,
case tok::kw_extern:
if (getLangOpts().CPlusPlus && NextToken().is(tok::kw_template)) {
+ ProhibitAttributes(Attrs);
AaronBallman wrote:
Thanks! So yeah. we're agreed,
https://github.com/AaronBallman commented:
Thank you for this!
I'd like to better understand the need for the changes because I have a few
concerns. One concern is about compile time performance. But also, this means
downstream consumers of the AST are going to have to react because they used
@@ -24,7 +24,7 @@ int templateFunction(T value)
__attribute__((annotate("works")));
// CHECK: ClassDecl=Test:3:7 (Definition) Extent=[3:1 - 17:2]
// CHECK-NEXT: CXXAccessSpecifier=:4:1 (Definition) Extent=[4:1 - 4:8]
-// CHECK-NEXT: CXXMethod=aMethod:5:51 Extent=[5:3 - 5:60]
AaronBallman wrote:
> Putting aside for now the naming issue ([#136038
> (comment)](https://github.com/llvm/llvm-project/pull/136038#discussion_r2049703902)),
> is there anything left for the changes proposed in this PR?
Based on:
> ... but I think "will this end up as an i1" is a fair summar
@@ -2336,16 +2336,9 @@ bool Type::isArithmeticType() const {
}
bool Type::hasBooleanRepresentation() const {
- if (isBooleanType())
-return true;
-
- if (const EnumType *ET = getAs())
-return ET->getDecl()->getIntegerType()->isBooleanType();
-
- if (const AtomicType
AaronBallman wrote:
> Yes, I'm very eager for this feature, let me investigate the RFC proposal
> routine.
I would recommend you also include details about how the extension meets our
[usual criteria](https://clang.llvm.org/get_involved.html#criteria) when you
write the RFC.
https://github.c
AaronBallman wrote:
> > If Insert or Remove is true, we should diagnose those as being deprecated
> > and recommend using disable-insert or disable-remove instead.
>
> `Insert` and `Remove` are true by default. Should it not be as false?
Oops, I meant "if they're used", so yes. :-)
> Also, th
@@ -1049,6 +1049,7 @@ Parser::ParseExternalDeclaration(ParsedAttributes &Attrs,
case tok::kw_extern:
if (getLangOpts().CPlusPlus && NextToken().is(tok::kw_template)) {
+ ProhibitAttributes(Attrs);
AaronBallman wrote:
I think it's reasonable to reje
Hana =?utf-8?q?Dusíková?= ,
Hana =?utf-8?q?Dusíková?=
Message-ID:
In-Reply-To:
AaronBallman wrote:
> IMO this kind of flag requires an RFC.
+1, this sort of extension requires an RFC. Please be sure to mention how the
RFC addresses our [usual
criteria](https://clang.llvm.org/get_involve
https://github.com/AaronBallman updated
https://github.com/llvm/llvm-project/pull/136323
>From 3beecb29772e13c6a1a41877e5e8cbbfb17a88f2 Mon Sep 17 00:00:00 2001
From: Aaron Ballman
Date: Fri, 18 Apr 2025 12:26:36 -0400
Subject: [PATCH 1/5] Control analysis-based diagnostics with #pra
@@ -202,6 +202,43 @@ class SemaPPCallbacks : public PPCallbacks {
break;
}
}
+ void PragmaDiagnostic(SourceLocation Loc, StringRef Namespace,
+diag::Severity Mapping, StringRef Str) override {
+// If one of the analysis-based diagnostics
AaronBallman wrote:
> > The current patch actually WILL work with it ONLY enabled on the line
> > inside of the function, which I think is much more intuitive.
>
> Ooo whoa this is awesome!!
Sorry for the confusion, I've updated the patch summary accordingly
https://github.com/llvm/llvm-proje
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/136323
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/AaronBallman updated
https://github.com/llvm/llvm-project/pull/136323
>From 3beecb29772e13c6a1a41877e5e8cbbfb17a88f2 Mon Sep 17 00:00:00 2001
From: Aaron Ballman
Date: Fri, 18 Apr 2025 12:26:36 -0400
Subject: [PATCH 1/5] Control analysis-based diagnostics with #pra
@@ -2493,9 +2493,10 @@ class sema::AnalysisBasedWarnings::InterProceduralData {
CalledOnceInterProceduralData CalledOnceData;
};
-static unsigned isEnabled(DiagnosticsEngine &D, unsigned diag) {
- return (unsigned)!D.isIgnored(diag, SourceLocation());
-}
+template
+static
@@ -2504,23 +2505,37 @@ sema::AnalysisBasedWarnings::AnalysisBasedWarnings(Sema
&s)
NumUninitAnalysisVariables(0), MaxUninitAnalysisVariablesPerFunction(0),
NumUninitAnalysisBlockVisits(0),
MaxUninitAnalysisBlockVisitsPerFunction(0) {
+}
+
+// We need this he
https://github.com/AaronBallman updated
https://github.com/llvm/llvm-project/pull/136323
>From 3beecb29772e13c6a1a41877e5e8cbbfb17a88f2 Mon Sep 17 00:00:00 2001
From: Aaron Ballman
Date: Fri, 18 Apr 2025 12:26:36 -0400
Subject: [PATCH 1/4] Control analysis-based diagnostics with #pra
@@ -2493,35 +2493,44 @@ class sema::AnalysisBasedWarnings::InterProceduralData {
CalledOnceInterProceduralData CalledOnceData;
};
-static unsigned isEnabled(DiagnosticsEngine &D, unsigned diag) {
- return (unsigned)!D.isIgnored(diag, SourceLocation());
+static bool isEnable
@@ -2493,35 +2493,44 @@ class sema::AnalysisBasedWarnings::InterProceduralData {
CalledOnceInterProceduralData CalledOnceData;
};
-static unsigned isEnabled(DiagnosticsEngine &D, unsigned diag) {
- return (unsigned)!D.isIgnored(diag, SourceLocation());
+static bool isEnable
@@ -1202,6 +1202,30 @@ Clang also allows you to push and pop the current
warning state. This is
particularly useful when writing a header file that will be compiled by
other people, because you don't know what warning flags they build with.
+Note that the following diagnostic
https://github.com/AaronBallman updated
https://github.com/llvm/llvm-project/pull/136323
>From 3beecb29772e13c6a1a41877e5e8cbbfb17a88f2 Mon Sep 17 00:00:00 2001
From: Aaron Ballman
Date: Fri, 18 Apr 2025 12:26:36 -0400
Subject: [PATCH 1/2] Control analysis-based diagnostics with #pra
@@ -0,0 +1,77 @@
+// RUN: %clang_cc1 -fsyntax-only -verify -Werror=unreachable-code-aggressive %s
+
+// Test that analysis-based warnings honor #pragma diagnostic controls. These
+// diagnostics are triggered at the end of a function body, so the pragma needs
+// to be enabled thr
@@ -1202,6 +1202,30 @@ Clang also allows you to push and pop the current
warning state. This is
particularly useful when writing a header file that will be compiled by
other people, because you don't know what warning flags they build with.
+Note that the following diagnostic
AaronBallman wrote:
> > Do we need a deprecation period for this change? This will break anyone
> > using the old names in scripts and whatnot.
> > Also, the changes will need something in the release notes so users know
> > about the new names.
>
> Is there a specific way to mark flags as dep
AaronBallman wrote:
> > @cor3ntin I question if `-Wloop-analysis` should be completely rewritten
> > using dataflow analysis, rather than AST based matching.
>
> That's an interesting idea, but I don't think that should stop us from
> landing this improvement. Maybe we want to open an issue fo
8f2 Mon Sep 17 00:00:00 2001
From: Aaron Ballman
Date: Fri, 18 Apr 2025 12:26:36 -0400
Subject: [PATCH] Control analysis-based diagnostics with #pragma
Previously, analysis-based diagnostics (like -Wconsumed) had to be
enabled at file scope in order to be run at the end of each function
body. T
1 - 100 of 5222 matches
Mail list logo
