https://github.com/AaronBallman closed
https://github.com/llvm/llvm-project/pull/142195
___
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/142195
Microsoft helpfully defines `THIS` to `void` in two different platform SDK
headers, at least one of which is reachable via . We have a user who
ran into a build because of `THIS` unfortunate macro name col
https://github.com/AaronBallman approved this pull request.
LGTM! Failing docs build in precommit CI appears to be unrelated
https://github.com/llvm/llvm-project/pull/139429
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org
https://github.com/AaronBallman approved this pull request.
LGTM!
https://github.com/llvm/llvm-project/pull/142163
___
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.
This looks reasonable to me, but please wait for @erichkeane to sign off before
landing
https://github.com/llvm/llvm-project/pull/137882
___
cfe-commits mailing list
cfe-commits@lists.llvm.or
@@ -0,0 +1,46 @@
+// RUN: %clang_cc1 %s -verify=expected -Wimplicit-int-conversion
+// RUN: %clang_cc1 %s -verify=none -Wimplicit-int-conversion
-Wno-implicit-int-conversion-on-negation
+
+// none-no-diagnostics
+
+char test_char(char x) {
+ return -x; // expected-warning {{impl
https://github.com/AaronBallman commented:
LGTM aside from a request for another test
https://github.com/llvm/llvm-project/pull/139429
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/139429
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
AaronBallman wrote:
We reviewed this thread today at the Clang Area Team meeting and it seems like
y'all have perhaps found a solution everyone is happy with. However, if you'd
like a meeting or if there's some other way we can support you, we're
definitely happy to help!
> Please let me know
AaronBallman wrote:
Due to inappropriate behavior from @BukeBeyond, the age of the PR, and the fact
that it's merged, I've locked the PR as resolved.
https://github.com/llvm/llvm-project/pull/115821
___
cfe-commits mailing list
cfe-commits@lists.llvm.
https://github.com/AaronBallman locked
https://github.com/llvm/llvm-project/pull/115821
___
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/141783
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -373,19 +373,21 @@ implementation of the facilities by Clang may change
behavior as bugs are
fixed, features get implemented, etc.
The library should be ABI and API stable over time, but ABI- and API-breaking
-changes can happen in the following situations:
+changes can ha
https://github.com/AaronBallman updated
https://github.com/llvm/llvm-project/pull/141783
>From deeb52c330fc0c1fbdbfe77403c1320d76fa460d Mon Sep 17 00:00:00 2001
From: Aaron Ballman
Date: Wed, 28 May 2025 10:51:07 -0400
Subject: [PATCH 1/5] [C23] Handle type compatibility of unnamed records
At
https://github.com/AaronBallman commented:
Thank you for working on this!
https://github.com/llvm/llvm-project/pull/139429
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -352,6 +352,9 @@ Improvements to Clang's diagnostics
- Now correctly diagnose a tentative definition of an array with static
storage duration in pedantic mode in C. (#GH50661)
+- Split diagnosis of implicit integer comparison on negation to a new
diagnostic group ``-Wimp
@@ -0,0 +1,64 @@
+// RUN: %clang_cc1 %s -verify -Wimplicit-int-conversion
+// RUN: %clang_cc1 %s -verify -Wimplicit-int-conversion
-Wno-implicit-int-conversion-on-negation -DNO_DIAG
+
+char test_char(char x) {
+ return -x;
+#ifndef NO_DIAG
+ // expected-warning@-2 {{implicit co
@@ -0,0 +1,64 @@
+// RUN: %clang_cc1 %s -verify -Wimplicit-int-conversion
+// RUN: %clang_cc1 %s -verify -Wimplicit-int-conversion
-Wno-implicit-int-conversion-on-negation -DNO_DIAG
AaronBallman wrote:
A better approach than using `-D` is to specify a prefix to
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/139429
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -359,3 +359,35 @@ struct alignment { // c17-error {{redefinition of
'alignment'}} \
c23-error {{type 'struct alignment' has a member with an
attribute which currently causes the types to be treated as though they are
incompatible}}
int x;
};
+
+//
https://github.com/AaronBallman updated
https://github.com/llvm/llvm-project/pull/141783
>From deeb52c330fc0c1fbdbfe77403c1320d76fa460d Mon Sep 17 00:00:00 2001
From: Aaron Ballman
Date: Wed, 28 May 2025 10:51:07 -0400
Subject: [PATCH 1/4] [C23] Handle type compatibility of unnamed records
At
https://github.com/AaronBallman updated
https://github.com/llvm/llvm-project/pull/141783
>From deeb52c330fc0c1fbdbfe77403c1320d76fa460d Mon Sep 17 00:00:00 2001
From: Aaron Ballman
Date: Wed, 28 May 2025 10:51:07 -0400
Subject: [PATCH 1/3] [C23] Handle type compatibility of unnamed records
At
AaronBallman wrote:
Precommit CI found relevant failures; it looks like clang-tools-extra needs
some updates as well
https://github.com/llvm/llvm-project/pull/137882
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bi
https://github.com/AaronBallman approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/141779
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1432,14 +1432,26 @@ void
NumericLiteralParser::ParseNumberStartingWithZero(SourceLocation TokLoc) {
Diags.Report(TokLoc, DiagId);
++s;
DigitsBegin = s;
-SawOctalPrefix = true;
+radix = 8;
AaronBallman wrote:
Oh, you're right, I missed
https://github.com/AaronBallman updated
https://github.com/llvm/llvm-project/pull/141783
>From deeb52c330fc0c1fbdbfe77403c1320d76fa460d Mon Sep 17 00:00:00 2001
From: Aaron Ballman
Date: Wed, 28 May 2025 10:51:07 -0400
Subject: [PATCH 1/2] [C23] Handle type compatibility of unnamed records
At
@@ -359,3 +359,29 @@ struct alignment { // c17-error {{redefinition of
'alignment'}} \
c23-error {{type 'struct alignment' has a member with an
attribute which currently causes the types to be treated as though they are
incompatible}}
int x;
};
+
+//
@@ -1751,9 +1751,20 @@ static bool
IsStructurallyEquivalent(StructuralEquivalenceContext &Context,
// fulfill the preceding requirements. ... Otherwise, the structure, union,
// or enumerated types are incompatible.
- if (!NameIsStructurallyEquivalent(*D1, *D2)) {
+ //
https://github.com/AaronBallman created
https://github.com/llvm/llvm-project/pull/141783
At the top-level, both types need to have a tag in order for them to be
compatible within the same TU in C23. An unnamed structure has no tag, so it
cannot be compatible with another type within the TU.
F
https://github.com/AaronBallman closed
https://github.com/llvm/llvm-project/pull/141747
___
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.
Clang bits LGTM!
https://github.com/llvm/llvm-project/pull/136098
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1432,14 +1432,26 @@ void
NumericLiteralParser::ParseNumberStartingWithZero(SourceLocation TokLoc) {
Diags.Report(TokLoc, DiagId);
++s;
DigitsBegin = s;
-SawOctalPrefix = true;
+radix = 8;
AaronBallman wrote:
There's code below which al
https://github.com/AaronBallman commented:
I added @cor3ntin and @tahonermann for some extra sets of eyes, seeing as how I
already messed this up once before. :-)
https://github.com/llvm/llvm-project/pull/141695
___
cfe-commits mailing list
cfe-commit
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/141695
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -358,3 +358,46 @@ Complete example code
.. _Index.h:
https://github.com/llvm/llvm-project/blob/main/clang/include/clang-c/Index.h
+
+.. _Stability:
+
+ABI and API Stability
+-
+
+The C interfaces in libclang are intended to be relatively stable. This a
https://github.com/AaronBallman updated
https://github.com/llvm/llvm-project/pull/141657
>From c7a41997f41daea5669e1a5b003e0b42699c56d4 Mon Sep 17 00:00:00 2001
From: Aaron Ballman
Date: Tue, 27 May 2025 14:52:35 -0400
Subject: [PATCH 1/4] [Docs] Explicitly document libclang ABI and API stabili
https://github.com/AaronBallman created
https://github.com/llvm/llvm-project/pull/141747
The assumption attribute is exposed with a Clang spelling, which means we
support __attribute__((assume)) as well as [[clang::assume]] as spellings for
the attribute.
In C++, the [[clang::assume]] spellin
AaronBallman wrote:
> If you feel that there's a technical reason that the compiler output is no
> longer reasonable, you are welcome to bring it up as a technical argument. My
> point is simply that "my transform stopped working because clang's compiler
> output changed" is not, in and of its
https://github.com/AaronBallman closed
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
@@ -7867,15 +7867,16 @@ void Sema::checkUnusedDeclAttributes(Declarator &D) {
void Sema::DiagnoseUnknownAttribute(const ParsedAttr &AL) {
std::string NormalizedFullName = '\'' + AL.getNormalizedFullName() + '\'';
+ SourceRange NR = AL.getNormalizedRange();
+ SourceLocation
@@ -5311,6 +5313,90 @@ void
Parser::ParseMicrosoftUuidAttributeArgs(ParsedAttributes &Attrs) {
}
}
+void Parser::ParseMicrosoftRootSignatureAttributeArgs(ParsedAttributes &Attrs)
{
+ assert(Tok.is(tok::identifier) &&
+ "Expected an identifier to denote which MS at
https://github.com/AaronBallman created
https://github.com/llvm/llvm-project/pull/141657
Our current docs leave a lot of latitude ("relatively stable") without
explaining what the goals are for this stability. This patch adds some basic
documentation explaining that there are some changes whic
https://github.com/AaronBallman closed
https://github.com/llvm/llvm-project/pull/141621
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
AaronBallman wrote:
> I think this problem is an important one to solve, and this is not the first
> time our rigid ABI has caused us problems. I wonder at what point we should
> decide to break ABI, because there are other cleanups we also want to do
> (removing deprecated APIs, for example).
AaronBallman wrote:
I've added a handful of folks who might be reasonable reviewers for this, but
if you know of anyone else who may have an opinion, feel free to rope them in.
These changes came about because of
https://github.com/llvm/llvm-project/pull/134551 where someone was trying to
add
AaronBallman wrote:
I think adding more attributes is a viable option, but it doesn't scale
particularly well and I would not be surprised if it caused some confusion in
practice.
> But maybe we can exclude functions where the attribute directly refers to a
> parameter.
This doesn't work for
@@ -3574,20 +3574,26 @@ ScalarExprEmitter::VisitUnaryExprOrTypeTraitExpr(
CGF.EmitIgnoredExpr(E->getArgumentExpr());
}
-auto VlaSize = CGF.getVLASize(VAT);
-llvm::Value *size = VlaSize.NumElts;
-
// For sizeof and __datasizeof, we nee
https://github.com/AaronBallman updated
https://github.com/llvm/llvm-project/pull/141621
>From b7736e6c6c6c39fab5a21059995a0dbf4eed4e2f Mon Sep 17 00:00:00 2001
From: Aaron Ballman
Date: Tue, 27 May 2025 11:30:00 -0400
Subject: [PATCH 1/2] [C2y] Fix _Countof handling of VLAs
It turns out that
https://github.com/AaronBallman created
https://github.com/llvm/llvm-project/pull/141621
It turns out that getVLASize() does not get you the size of a single dimension
of the VLA, it gets you the full count of all elements. This caused _Countof to
return invalid values on VLA ranks. Now switch
https://github.com/AaronBallman closed
https://github.com/llvm/llvm-project/pull/141596
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1874,9 +1874,11 @@ ExprResult Sema::CreateGenericSelectionExpr(
if (D != 0) {
Diag(Types[i]->getTypeLoc().getBeginLoc(), D)
-<< Types[i]->getTypeLoc().getSourceRange()
-<< Types[i]->getType();
- TypeErrorFound = true;
+
@@ -1874,9 +1874,11 @@ ExprResult Sema::CreateGenericSelectionExpr(
if (D != 0) {
Diag(Types[i]->getTypeLoc().getBeginLoc(), D)
-<< Types[i]->getTypeLoc().getSourceRange()
-<< Types[i]->getType();
- TypeErrorFound = true;
+
@@ -1874,9 +1874,11 @@ ExprResult Sema::CreateGenericSelectionExpr(
if (D != 0) {
Diag(Types[i]->getTypeLoc().getBeginLoc(), D)
-<< Types[i]->getTypeLoc().getSourceRange()
-<< Types[i]->getType();
- TypeErrorFound = true;
+
https://github.com/AaronBallman approved this pull request.
LGTM!
https://github.com/llvm/llvm-project/pull/141307
___
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/141596
We were emitting a non-error diagnostic but claiming we emitted an error, which
caused some obvious follow-on problems.
Fixes #141549
>From a3509b043c9b36decdb3e891ac4e808c3d907827 Mon Sep 17 00:00:00 200
@@ -0,0 +1,32 @@
+// RUN: %clang_cc1 -Wunknown-attributes -fsyntax-only -verify %s
+// RUN: %clang_cc1 -Wunknown-attributes -fsyntax-only
-fdiagnostics-parseable-fixits %s 2>&1 | FileCheck %s
+
+[[gmu::deprected]] // expected-warning {{unknown attribute 'gmu::deprected'
ignored;
@@ -7867,15 +7867,16 @@ void Sema::checkUnusedDeclAttributes(Declarator &D) {
void Sema::DiagnoseUnknownAttribute(const ParsedAttr &AL) {
std::string NormalizedFullName = '\'' + AL.getNormalizedFullName() + '\'';
+ SourceRange NR = AL.getNormalizedRange();
+ SourceLocation
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
1 - 100 of 3040 matches
Mail list logo
