https://github.com/AaronBallman approved this pull request.
LGTM!
https://github.com/llvm/llvm-project/pull/141090
___
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/140890
>From 10cb78bd9f361dd442c40702dad3c7809f466615 Mon Sep 17 00:00:00 2001
From: Aaron Ballman
Date: Wed, 21 May 2025 08:59:47 -0400
Subject: [PATCH 1/4] [C2y] Add stdcountof.h
WG14 N3469 changed _Lengthof to
@@ -389,6 +389,7 @@ SYMBOL(cosh, None, )
SYMBOL(coshf, None, )
SYMBOL(coshl, None, )
SYMBOL(cosl, None, )
+SYMBOL(countof, None, )
AaronBallman wrote:
Yup, I missed:
```
// Generated from cppreference offline HTML book (modified on 2018-10-28).
//===--
AaronBallman wrote:
> > It means all such string accesses would require two indirections to get to
> > the string data
>
> I don't think that's true. Getting the pointer would be `ptr+sizeof(size_t)`.
>
> > I also wonder if we want to be slightly less memory efficient and add a
> > version fi
AaronBallman wrote:
> > I think we need to understand what we want before we can make decisions on
> > what needs changing, though. Are there invariants we want to introduce,
> > like the source range for the AST node should encompass the source
> > locations tracked within the AST node? Or ar
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/141058
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -2901,34 +2907,44 @@ class CallExpr : public Expr {
//
// * An optional of type FPOptionsOverride.
//
- // Note that we store the offset in bytes from the this pointer to the start
- // of the trailing objects. It would be perfectly possible to compute it
- // based
@@ -2901,34 +2907,44 @@ class CallExpr : public Expr {
//
// * An optional of type FPOptionsOverride.
//
- // Note that we store the offset in bytes from the this pointer to the start
- // of the trailing objects. It would be perfectly possible to compute it
- // based
@@ -3187,9 +3216,59 @@ class CallExpr : public Expr {
SourceLocation getRParenLoc() const { return RParenLoc; }
void setRParenLoc(SourceLocation L) { RParenLoc = L; }
- SourceLocation getBeginLoc() const LLVM_READONLY;
- SourceLocation getEndLoc() const LLVM_READONLY;
+
@@ -1510,41 +1519,41 @@ CallExpr *CallExpr::Create(const ASTContext &Ctx, Expr
*Fn,
unsigned NumArgs = std::max(Args.size(), MinNumArgs);
unsigned SizeOfTrailingObjects = CallExpr::sizeOfTrailingObjects(
/*NumPreArgs=*/0, NumArgs, FPFeatures.requiresTrailingStorage()
@@ -1510,41 +1519,41 @@ CallExpr *CallExpr::Create(const ASTContext &Ctx, Expr
*Fn,
unsigned NumArgs = std::max(Args.size(), MinNumArgs);
unsigned SizeOfTrailingObjects = CallExpr::sizeOfTrailingObjects(
/*NumPreArgs=*/0, NumArgs, FPFeatures.requiresTrailingStorage()
@@ -3187,9 +3216,59 @@ class CallExpr : public Expr {
SourceLocation getRParenLoc() const { return RParenLoc; }
void setRParenLoc(SourceLocation L) { RParenLoc = L; }
- SourceLocation getBeginLoc() const LLVM_READONLY;
- SourceLocation getEndLoc() const LLVM_READONLY;
+
https://github.com/AaronBallman commented:
Thank you for working on this!
https://github.com/llvm/llvm-project/pull/141058
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
AaronBallman wrote:
> https://llvm-compile-time-tracker.com/compare.php?from=f4cebe5d73c24ab53917bd58aedc9db892a164ae&to=99d11a55c0222e8ed64aa35a068a3f08673baaba&stat=instructions%3Au
There is so much green!
https://github.com/llvm/llvm-project/pull/141058
__
AaronBallman wrote:
> We could keep `CXString` as it was before, but `const void *data` could
> actually point to a dynamically allocated struct that has roughly this
> definition:
>
> ```c
> struct Data {
> size_t length;
> char data[1];
> };
> ```
>
> This wouldn't change the curre
@@ -49,6 +49,11 @@ module cstd [system] [no_undeclared_includes] {
export *
}
+ module stdcountof {
+header "stdcountof.h"
+export *
+ }
+
AaronBallman wrote:
Good catch! I've updated that test as well.
https://github.com/llvm/llvm-project/pu
https://github.com/AaronBallman updated
https://github.com/llvm/llvm-project/pull/140890
>From 10cb78bd9f361dd442c40702dad3c7809f466615 Mon Sep 17 00:00:00 2001
From: Aaron Ballman
Date: Wed, 21 May 2025 08:59:47 -0400
Subject: [PATCH 1/3] [C2y] Add stdcountof.h
WG14 N3469 changed _Lengthof to
AaronBallman wrote:
> Thanks for the review. I’ve implemented all the requested changes but still
> have a few questions:
>
> * Originally, using `IVTy` to query the iteration variable’s width always
> returned “32-bit int,” even if the loop was declared as `char` or `short`. As
> a resul
@@ -14924,6 +14924,21 @@ StmtResult
SemaOpenMP::ActOnOpenMPUnrollDirective(ArrayRef Clauses,
SourceLocation FactorLoc;
if (Expr *FactorVal = PartialClause->getFactor();
FactorVal && !FactorVal->containsErrors()) {
+if (!VerifyPositiveIntegerConstantInClause(Facto
@@ -14924,6 +14924,21 @@ StmtResult
SemaOpenMP::ActOnOpenMPUnrollDirective(ArrayRef Clauses,
SourceLocation FactorLoc;
if (Expr *FactorVal = PartialClause->getFactor();
FactorVal && !FactorVal->containsErrors()) {
+if (!VerifyPositiveIntegerConstantInClause(Facto
https://github.com/AaronBallman approved this pull request.
Please add a release note to `clang/docs/ReleaseNotes.rst` so users know about
the new functionality and flag.
Otherwise, LGTM!
https://github.com/llvm/llvm-project/pull/138562
___
cfe-commi
AaronBallman wrote:
> Thanks Aaron, that's a good example.
>
> This is a pickle; it doesn't seem like there's an obviously Right
> Solution(tm) here.
That's the same conclusion I'm coming to. These situations are kind of mutually
exclusive.
> I think we're agreeing on the first part, that un
https://github.com/AaronBallman closed
https://github.com/llvm/llvm-project/pull/140925
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/AaronBallman closed
https://github.com/llvm/llvm-project/pull/140828
___
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/140828
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/AaronBallman created
https://github.com/llvm/llvm-project/pull/140925
There are two related issues being fixed in this patch. Both issues relate to
use of an invalid structure which contains a member that we error recover such
that the field has the same type as the structur
https://github.com/AaronBallman created
https://github.com/llvm/llvm-project/pull/140890
WG14 N3469 changed _Lengthof to _Countof but it also introduced the
header to expose a macro with a non-ugly identifier. GCC vends
this header as part of the compiler implementation, so Clang should do th
AaronBallman wrote:
> I still have no problem with this, but it is now into things I have zero
> confidence reviewing :) Please have someone who has ever used modules review
> this.
I've added some modules reviewers, so hopefully they can take a look. Yeah, I
agree that tablegen would be a ni
https://github.com/AaronBallman updated
https://github.com/llvm/llvm-project/pull/140890
>From 10cb78bd9f361dd442c40702dad3c7809f466615 Mon Sep 17 00:00:00 2001
From: Aaron Ballman
Date: Wed, 21 May 2025 08:59:47 -0400
Subject: [PATCH 1/2] [C2y] Add stdcountof.h
WG14 N3469 changed _Lengthof to
AaronBallman wrote:
Precommit CI caught a relevant failure that only happens when testing against
an install target, so yay for that! I've got a fix coming along with some other
updated support files I found when looking at stdalign.h
https://github.com/llvm/llvm-project/pull/140890
__
@@ -7639,6 +7639,8 @@ def warn_param_mismatched_alignment : Warning<
def err_objc_object_assignment : Error<
"cannot assign to class object (%0 invalid)">;
+def err_typecheck_array_prvalue_operand : Error<
+ "array prvalue is not permitted">;
AaronBallman w
AaronBallman wrote:
CC @alejandro-colomar
https://github.com/llvm/llvm-project/pull/140890
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
AaronBallman wrote:
> > > @AaronBallman
> > > I'm not sure who's responsible for `` in LLVM.
> >
> >
> > Yeah, it's never really clear who is expected to provide these headers.
> > > In GCC it's a header provided by the compiler. I see that this PR does
> > > not add the header, so I was wonde
@@ -0,0 +1,12 @@
+// RUN: %clang_cc1 -triple riscv64 -ast-dump -ast-dump-filter c23 -std=c23 -x
c %s | FileCheck --strict-whitespace %s
+
+// CHECK: FunctionDecl{{.*}}pre_c23
+// CHECK-NEXT:|-CompoundStmt
+// CHECK-NEXT:`-RISCVInterruptAttr{{.*}}supervisor
+__attrib
AaronBallman wrote:
> @AaronBallman
>
> I'm not sure who's responsible for `` in LLVM.
Yeah, it's never really clear who is expected to provide these headers.
> In GCC it's a header provided by the compiler. I see that this PR does not
> add the header, so I was wondering if that's to be adde
https://github.com/AaronBallman commented:
Thank you for working on this! In general, this looks good to me, just nits
about our coding style.
https://github.com/llvm/llvm-project/pull/140828
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
htt
@@ -3727,12 +3734,26 @@ static void GenerateHasAttrSpellingStringSwitch(
}
}
-std::string TestStr = !Test.empty()
- ? Test + " ? " + itostr(Version) + " : 0"
- : itostr(Version);
-if (Scope.empty() ||
@@ -3727,12 +3734,26 @@ static void GenerateHasAttrSpellingStringSwitch(
}
}
-std::string TestStr = !Test.empty()
- ? Test + " ? " + itostr(Version) + " : 0"
- : itostr(Version);
-if (Scope.empty() ||
@@ -3727,12 +3734,26 @@ static void GenerateHasAttrSpellingStringSwitch(
}
}
-std::string TestStr = !Test.empty()
- ? Test + " ? " + itostr(Version) + " : 0"
- : itostr(Version);
-if (Scope.empty() ||
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/140828
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -7639,6 +7639,8 @@ def warn_param_mismatched_alignment : Warning<
def err_objc_object_assignment : Error<
"cannot assign to class object (%0 invalid)">;
+def err_typecheck_array_prvalue_operand : Error<
+ "array prvalue is not permitted">;
AaronBallman w
@@ -7639,6 +7639,8 @@ def warn_param_mismatched_alignment : Warning<
def err_objc_object_assignment : Error<
"cannot assign to class object (%0 invalid)">;
+def err_typecheck_array_prvalue_operand : Error<
+ "array prvalue is not permitted">;
AaronBallman w
AaronBallman wrote:
> > it is CWG2548; that's what made it clear that array-to-pointer decay does
> > not happen here
>
> CWG2548 is closed as NAD, with no changes to the wording.
Correct.
> The fact that array-to-pointer decay does not happen has always been clear
Incorrect; the reason the
https://github.com/AaronBallman approved this pull request.
LGTM!
https://github.com/llvm/llvm-project/pull/140233
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -7639,6 +7639,8 @@ def warn_param_mismatched_alignment : Warning<
def err_objc_object_assignment : Error<
"cannot assign to class object (%0 invalid)">;
+def err_typecheck_array_prvalue_operand : Error<
+ "array prvalue is not permitted">;
AaronBallman w
AaronBallman wrote:
> > This is related to CWG2548
>
> Kinda, but not really. It has never been necessary to create that
> (non-)issue. Or does someone really believe that it is a C++ defect that `IA{
> 1, 2, 3 } - IA{ 1, 2, 3 }` is not allowed? So, it is just a bug since C++11
I think it is
https://github.com/AaronBallman closed
https://github.com/llvm/llvm-project/pull/140724
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/AaronBallman requested changes to this pull request.
Precommit CI failures look related to this patch:
```
/var/lib/buildkite-agent/builds/linux-56-59b8f5d88-g6cdk-1/llvm-project/github-pull-requests/build-runtimes/include/c++/v1/__type_traits/invoke.h:123:29:
error: variable
@@ -5406,6 +5408,99 @@ ExprResult Sema::ConvertVectorExpr(Expr *E,
TypeSourceInfo *TInfo,
RParenLoc, CurFPFeatureOverrides());
}
+ExprResult Sema::BuiltinInvoke(CallExpr *TheCall) {
+ SourceLocation Loc = TheCall->getBeginLoc();
+ auto Arg
@@ -5406,6 +5408,99 @@ ExprResult Sema::ConvertVectorExpr(Expr *E,
TypeSourceInfo *TInfo,
RParenLoc, CurFPFeatureOverrides());
}
+ExprResult Sema::BuiltinInvoke(CallExpr *TheCall) {
+ SourceLocation Loc = TheCall->getBeginLoc();
+ auto Arg
@@ -5406,6 +5408,99 @@ ExprResult Sema::ConvertVectorExpr(Expr *E,
TypeSourceInfo *TInfo,
RParenLoc, CurFPFeatureOverrides());
}
+ExprResult Sema::BuiltinInvoke(CallExpr *TheCall) {
+ SourceLocation Loc = TheCall->getBeginLoc();
+ auto Arg
https://github.com/AaronBallman commented:
Please also update `clang/docs/LanguageExtensions.rst` to document the new
builtin, and update `clang/docs/ReleaseNotes.rst` so users know about the new
functionality.
https://github.com/llvm/llvm-project/pull/116709
__
@@ -5406,6 +5408,99 @@ ExprResult Sema::ConvertVectorExpr(Expr *E,
TypeSourceInfo *TInfo,
RParenLoc, CurFPFeatureOverrides());
}
+ExprResult Sema::BuiltinInvoke(CallExpr *TheCall) {
+ SourceLocation Loc = TheCall->getBeginLoc();
+ auto Arg
@@ -5406,6 +5408,99 @@ ExprResult Sema::ConvertVectorExpr(Expr *E,
TypeSourceInfo *TInfo,
RParenLoc, CurFPFeatureOverrides());
}
+ExprResult Sema::BuiltinInvoke(CallExpr *TheCall) {
+ SourceLocation Loc = TheCall->getBeginLoc();
+ auto Arg
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/116709
___
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/140571
>From e63781710d4f4307f4201670d96df9b511ad9551 Mon Sep 17 00:00:00 2001
From: Aaron Ballman
Date: Mon, 19 May 2025 12:33:24 -0400
Subject: [PATCH] Fix crash with delayed typo correction
Delayed typo correc
https://github.com/AaronBallman updated
https://github.com/llvm/llvm-project/pull/140578
>From 625662da41256345c4609835754c3a61018b54ca Mon Sep 17 00:00:00 2001
From: Aaron Ballman
Date: Mon, 19 May 2025 13:09:03 -0400
Subject: [PATCH 1/2] [C] Do not diagnose flexible array members with
-Wdefa
https://github.com/AaronBallman closed
https://github.com/llvm/llvm-project/pull/140725
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -203,10 +221,47 @@ unsigned
AttributeCommonInfo::calculateAttributeSpellingListIndex() const {
// attribute spell list index matching code.
auto Syntax = static_cast(getSyntax());
StringRef ScopeName = normalizeAttrScopeName(getScopeName(), Syntax);
- StringRef Name
https://github.com/AaronBallman commented:
In general, I think this is heading in the right direction.
https://github.com/llvm/llvm-project/pull/137882
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listi
@@ -396,9 +396,12 @@ any option of a multiversioned function is undefined.
}];
}
-def SYCLKernelDocs : Documentation {
+def DeviceKernelDocs : Documentation {
let Category = DocCatFunction;
+ let Heading = "device_kernel";
AaronBallman wrote:
We should
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/137882
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
AaronBallman wrote:
> > That probably should continue to work -- we accept it today and so does GCC
>
> GCC started accepting it from version 14, likely when fixing
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94264 (it is mentioned in
> [#54016
> (comment)](https://github.com/llvm/llvm-pro
AaronBallman wrote:
> However, it "breaks" compound literal C++ extension:
>
> ```
> $ build/bin/clang++ -fsyntax-only test.cxx
> test.cxx:12:2: error: array prvalue is not permitted
>12 | *((int []){ 1, 2, 3});
> | ^
> test.cxx:13:23: error: array
AaronBallman wrote:
> > Is this going to break behavior in C?
>
> Array **prvalues** is C++11+ exclusive thing. Compound literals are lvalues
> in C
Ah, good point, I wasn't remembering that C and C++ are different in how they
handle compound literals. And you can return a pointer to an arra
@@ -14,6 +14,8 @@
#include "clang/Basic/DiagnosticParse.h"
#include "clang/Parse/Parser.h"
#include "clang/Sema/ParsedTemplate.h"
+#include "clang/Tooling/Inclusions/StandardLibrary.h"
AaronBallman wrote:
This seems like a layering violation, though not a circ
@@ -9966,8 +9966,13 @@ AssignConvertType
Sema::CheckSingleAssignmentConstraints(QualType LHSType,
// If there is a conversion of some kind, check to see what kind of
// pointer conversion happened so we can diagnose a C++ compatibility
// diagnostic if the co
https://github.com/AaronBallman commented:
Is this going to break behavior in C? https://godbolt.org/z/PsPPs8ov1
https://github.com/llvm/llvm-project/pull/140702
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mai
@@ -85,3 +85,33 @@ void func() {
static const int b; // zero-init-var-warning {{default initialization of an
object of type 'const int' is incompatible with C++}} \
cxx-error {{default initialization of an object of
const type 'const int'}}
}
+
+//
@@ -9966,8 +9966,13 @@ AssignConvertType
Sema::CheckSingleAssignmentConstraints(QualType LHSType,
// If there is a conversion of some kind, check to see what kind of
// pointer conversion happened so we can diagnose a C++ compatibility
// diagnostic if the co
@@ -9966,8 +9966,13 @@ AssignConvertType
Sema::CheckSingleAssignmentConstraints(QualType LHSType,
// If there is a conversion of some kind, check to see what kind of
// pointer conversion happened so we can diagnose a C++ compatibility
// diagnostic if the co
https://github.com/AaronBallman created
https://github.com/llvm/llvm-project/pull/140725
A default-initialized union with a const member is generally reasonable in C
and isn't necessarily incompatible with C++, so we now silence the diagnostic
in that case. However, we do still diagnose a cons
AaronBallman wrote:
> > Just to confirm: is it intended that `char *s = NULL;` now generates this
> > warning? I mean, the C library may define `NULL` as `((void*)0)`, and `char
> > *s = ((void*)0);` is clearly not C++-compatible. However, when compiling
> > this code in C++, `NULL` may expand
https://github.com/AaronBallman created
https://github.com/llvm/llvm-project/pull/140724
This silences the diagnostic when the right-hand side is a null pointer
constant that comes from a macro expansion, such as NULL. However, we do not
limit to just NULL because other custom macros may expan
https://github.com/AaronBallman updated
https://github.com/llvm/llvm-project/pull/140578
>From 625662da41256345c4609835754c3a61018b54ca Mon Sep 17 00:00:00 2001
From: Aaron Ballman
Date: Mon, 19 May 2025 13:09:03 -0400
Subject: [PATCH 1/2] [C] Do not diagnose flexible array members with
-Wdefa
@@ -6513,6 +6513,14 @@ static bool canPerformArrayCopy(const InitializedEntity
&Entity) {
static const FieldDecl *getConstField(const RecordDecl *RD) {
assert(!isa(RD) && "Only expect to call this in C mode");
for (const FieldDecl *FD : RD->fields()) {
+// If the field
@@ -85,3 +85,33 @@ void func() {
static const int b; // zero-init-var-warning {{default initialization of an
object of type 'const int' is incompatible with C++}} \
cxx-error {{default initialization of an object of
const type 'const int'}}
}
+
+//
@@ -85,3 +85,33 @@ void func() {
static const int b; // zero-init-var-warning {{default initialization of an
object of type 'const int' is incompatible with C++}} \
cxx-error {{default initialization of an object of
const type 'const int'}}
}
+
+//
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/140578
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1351,7 +1352,8 @@ def OSConsumesThis : InheritableAttr {
def Cleanup : InheritableAttr {
let Spellings = [GCC<"cleanup">];
- let Args = [DeclArgument];
+ let Args = [DeclArgument,
+ ExprArgument<"Expr", /*opt=*/0, /*fake=*/1>];
AaronBallma
AaronBallman wrote:
> Just to confirm: is it intended that `char *s = NULL;` now generates this
> warning? I mean, the C library may define `NULL` as `((void*)0)`, and `char
> *s = ((void*)0);` is clearly not C++-compatible. However, when compiling this
> code in C++, `NULL` may expand to some
AaronBallman wrote:
> So @Rajveer100 : I think I bottomed out with Aaron. I think the solution of
> 'create a function to diagnose these, but only if not in a dependent
> `DeclContext`', then call this both from where we do the current checking,
> plus during `TreeTransform` of these things is
@@ -1351,7 +1352,8 @@ def OSConsumesThis : InheritableAttr {
def Cleanup : InheritableAttr {
let Spellings = [GCC<"cleanup">];
- let Args = [DeclArgument];
+ let Args = [DeclArgument,
+ ExprArgument<"Expr", /*opt=*/0, /*fake=*/1>];
AaronBallma
@@ -1351,7 +1352,8 @@ def OSConsumesThis : InheritableAttr {
def Cleanup : InheritableAttr {
let Spellings = [GCC<"cleanup">];
- let Args = [DeclArgument];
+ let Args = [DeclArgument,
+ ExprArgument<"Expr", /*opt=*/0, /*fake=*/1>];
AaronBallma
AaronBallman wrote:
> I would be against said RFC. If you asked me in 1996/whatever, I could be
> talked into it. But we're 30+ years of this behavior.
Doesn't stop WG21 from changing the behavior 30 years later. ;-) My biggest
concern is actually that C++ is changing exception handling such t
@@ -1351,7 +1352,8 @@ def OSConsumesThis : InheritableAttr {
def Cleanup : InheritableAttr {
let Spellings = [GCC<"cleanup">];
- let Args = [DeclArgument];
+ let Args = [DeclArgument,
+ ExprArgument<"Expr", /*opt=*/0, /*fake=*/1>];
AaronBallma
AaronBallman wrote:
> I feel like this issue is a little too niche to be adding such complexity,
> maybe just covering those specific uses cases before codegen might be the way
> to go?
I think disabling the keywords entirely is a large ask (requires an RFC at a
minimum) and so we don't need
@@ -1351,7 +1352,8 @@ def OSConsumesThis : InheritableAttr {
def Cleanup : InheritableAttr {
let Spellings = [GCC<"cleanup">];
- let Args = [DeclArgument];
+ let Args = [DeclArgument,
+ ExprArgument<"Expr", /*opt=*/0, /*fake=*/1>];
AaronBallma
AaronBallman wrote:
Linux precommit CI failure looks to be unrelated. Given that this is an
interaction between Sema and CodeGen, I'd like at least one approval from John
or Eli before I land.
https://github.com/llvm/llvm-project/pull/140571
___
cfe-
https://github.com/AaronBallman created
https://github.com/llvm/llvm-project/pull/140578
This addresses post-commit review feedback from someone who discovered that we
diagnosed code like the following:
```
struct S {
int len;
const char fam[];
} s;
```
despite it being invalid to i
https://github.com/AaronBallman created
https://github.com/llvm/llvm-project/pull/140571
Delayed typo correction does not emit a diagnostic until the end of the
TU. However, codegen is run on each top-level declaration unless an
unrecoverable error occurred. The check for the diagnostic ensures
AaronBallman wrote:
> Hi -- it looks like this pullreq may be causing a new spurious warning for
> the case where the const object is a C flexible array member. In that case
> there's no memory to initialize, but clang now warns anyway. More details in
> this comment on the associated bug repo
https://github.com/AaronBallman closed
https://github.com/llvm/llvm-project/pull/140542
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -14608,6 +14608,10 @@ void Sema::CheckCompleteVariableDeclaration(VarDecl
*var) {
std::optional CacheHasConstInit;
const Expr *CacheCulprit = nullptr;
auto checkConstInit = [&]() mutable {
+const Expr *Init = var->getInit();
+if (Init->isInstantiationDependent
@@ -14622,7 +14622,8 @@ void Sema::CheckCompleteVariableDeclaration(VarDecl
*var) {
Diag(var->getLocation(), diag::err_thread_nontrivial_dtor);
if (getLangOpts().CPlusPlus11)
Diag(var->getLocation(), diag::note_use_thread_local);
-} else if (getLangOpts
https://github.com/AaronBallman updated
https://github.com/llvm/llvm-project/pull/140542
>From a7aa9409530b5a11811149a612886f3d2f4bc977 Mon Sep 17 00:00:00 2001
From: Aaron Ballman
Date: Mon, 19 May 2025 09:31:51 -0400
Subject: [PATCH 1/2] [C++] Fix a crash with __thread and dependent types
We
@@ -14622,7 +14622,8 @@ void Sema::CheckCompleteVariableDeclaration(VarDecl
*var) {
Diag(var->getLocation(), diag::err_thread_nontrivial_dtor);
if (getLangOpts().CPlusPlus11)
Diag(var->getLocation(), diag::note_use_thread_local);
-} else if (getLangOpts
https://github.com/AaronBallman created
https://github.com/llvm/llvm-project/pull/140542
We were checking whether the initializer is a valid constant expression even if
the variable was dependent. Now we delay that checking until after the template
has been instantiated.
Fixes #140509
>From
AaronBallman wrote:
> In C++26, exceptions are allowed in a constant evaluated context, which is
> used extensively by reflection and maybe P2300.
Good point. :-/
> I also think allowing `try` not to be a keyword in some modes would harm the
> ecosystem.
[citation needed]
You already cannot
AaronBallman wrote:
> > I question if -Wloop-analysis should be completely rewritten using dataflow
> > analysis, rather than AST based matching.
>
> should changes inside functions be handled in the following cases?
>
> https://github.com/llvm/llvm-project/blob/db0f754c5af8e6c96770533520bf8b1
1 - 100 of 2983 matches
Mail list logo
