https://github.com/AaronBallman commented:
Thanks for the PR! I think we need to think about this a little bit; my concern
is that folks often use clang-query to write queries they'll eventually be
using in clang-tidy checks. However, the tidy checks are using the C++ DSL
which won't support t
https://github.com/AaronBallman approved this pull request.
LGTM aside from a nit with the comments (sorry for causing that confusion in
the first place).
https://github.com/llvm/llvm-project/pull/148090
___
cfe-commits mailing list
cfe-commits@lists.
@@ -2902,28 +2902,41 @@ static void handleWarnUnusedResult(Sema &S, Decl *D,
const ParsedAttr &AL) {
}
StringRef Str;
- if (AL.isStandardAttributeSyntax() && !AL.getScopeName()) {
-// The standard attribute cannot be applied to variable declarations such
-// as
@@ -2902,28 +2902,41 @@ static void handleWarnUnusedResult(Sema &S, Decl *D,
const ParsedAttr &AL) {
}
StringRef Str;
- if (AL.isStandardAttributeSyntax() && !AL.getScopeName()) {
-// The standard attribute cannot be applied to variable declarations such
-// as
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/148090
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
AaronBallman wrote:
> > I suppose another option is to use a regex in the test to accept either
> > form of canonicalization with a comment that lit tests are sometimes run
> > from network mounts and that's why the test is the way it is.
>
> I mean, at that point we can just delete the test e
AaronBallman wrote:
> > Windows doesn't have `/tmp` for example. I don't think we have any
> > [substitutions](https://llvm.org/docs/CommandGuide/lit.html#substitutions)
> > for getting the temp directory.
>
> Ah, I meant non-windows systems (I thought `REQUIRES: shell` already meant
> non-wi
AaronBallman wrote:
> We could try that (assuming that `/tmp` exists on every system but I sure
> hope so); it might run into issues if we somehow pick a file/directory name
> that something else is already using, but that’s probably not too likely.
Windows doesn't have `/tmp` for example. I d
AaronBallman wrote:
> Given the scale of the patch, it's not surprising if it undergoes some
> revert-reapplies cycles after the initial commit.
>
> To reduce the churn, would it be possible to ask google (and other major
> downstream clients) to test it internally before we merge? @AaronBallm
AaronBallman wrote:
I don't think we have a way to support that. I looked through lit to see what
kind of `REQUIRES` support we have and we can target systems and such, but I
don't see any built-in support for non-network mounts.
The only suggestion I have might be terrible, but you could writ
https://github.com/AaronBallman closed
https://github.com/llvm/llvm-project/pull/147802
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
AaronBallman wrote:
Another concrete reason for why this should default to an error for `_Atomic`
is https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p0943r6.html
In the C++ version of `stdatomic.h`, there's a `#define _Atomic(x)
std::atomic` which exists for shared header files betwee
https://github.com/AaronBallman updated
https://github.com/llvm/llvm-project/pull/147802
>From e65fa6bdd251ceef52e11ff8ee856058e8e3c47a Mon Sep 17 00:00:00 2001
From: Aaron Ballman
Date: Wed, 9 Jul 2025 14:40:00 -0400
Subject: [PATCH 1/9] [C23] Accept an _Atomic underlying type
The underlying
@@ -9364,6 +9364,14 @@ def warn_atomic_implicit_seq_cst : Warning<
InGroup>, DefaultIgnore;
def err_atomic_unsupported : Error<
"atomic types are not supported in '%0'">;
+def warn_cv_stripped_in_enum : Warning<
+ "%select{'const' and 'volatile' qualifiers|'const' qualifie
https://github.com/AaronBallman updated
https://github.com/llvm/llvm-project/pull/147802
>From e65fa6bdd251ceef52e11ff8ee856058e8e3c47a Mon Sep 17 00:00:00 2001
From: Aaron Ballman
Date: Wed, 9 Jul 2025 14:40:00 -0400
Subject: [PATCH 1/8] [C23] Accept an _Atomic underlying type
The underlying
https://github.com/AaronBallman updated
https://github.com/llvm/llvm-project/pull/147802
>From e65fa6bdd251ceef52e11ff8ee856058e8e3c47a Mon Sep 17 00:00:00 2001
From: Aaron Ballman
Date: Wed, 9 Jul 2025 14:40:00 -0400
Subject: [PATCH 1/7] [C23] Accept an _Atomic underlying type
The underlying
@@ -9364,6 +9364,14 @@ def warn_atomic_implicit_seq_cst : Warning<
InGroup>, DefaultIgnore;
def err_atomic_unsupported : Error<
"atomic types are not supported in '%0'">;
+def warn_cv_stripped_in_enum : Warning<
+ "%select{'const' and 'volatile' qualifiers|'const' qualifie
AaronBallman wrote:
> > > > avior due to the silent stripping. Given that an atomic type is not the
> > > > same as its underlying type (in terms of ABI or semantics) I think we
> > > > should diagnose the behavior with at least a warning. I could even be
> > > > convinced it should be a warni
https://github.com/AaronBallman updated
https://github.com/llvm/llvm-project/pull/147802
>From e65fa6bdd251ceef52e11ff8ee856058e8e3c47a Mon Sep 17 00:00:00 2001
From: Aaron Ballman
Date: Wed, 9 Jul 2025 14:40:00 -0400
Subject: [PATCH 1/6] [C23] Accept an _Atomic underlying type
The underlying
AaronBallman wrote:
> > avior due to the silent stripping. Given that an atomic type is not the
> > same as its underlying type (in terms of ABI or semantics) I think we
> > should diagnose the behavior with at least a warning. I could even be
> > convinced it should be a warning which default
@@ -17563,6 +17573,16 @@ Sema::ActOnTag(Scope *S, unsigned TagSpec, TagUseKind
TUK, SourceLocation KWLoc,
UPPC_FixedUnderlyingType))
EnumUnderlying = Context.IntTy.getTypePtr();
+ // If the underlying type is atomic, we n
@@ -2022,8 +2022,14 @@ Decl *TemplateDeclInstantiator::VisitEnumDecl(EnumDecl
*D) {
DeclarationName());
if (!NewTI || SemaRef.CheckEnumUnderlyingType(NewTI))
Enum->setIntegerType(SemaRef.Context.IntTy);
- else
@@ -174,10 +174,11 @@ def note_constexpr_heap_alloc_limit_exceeded : Note<
def note_constexpr_this : Note<
"%select{|implicit }0use of 'this' pointer is only allowed within the "
"evaluation of a call to a 'constexpr' member function">;
-def access_kind : TextSubstitution<
https://github.com/AaronBallman approved this pull request.
LGTM!
https://github.com/llvm/llvm-project/pull/147711
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -265,7 +265,7 @@ namespace const_modify {
namespace null {
constexpr int test(int *p) {
-return *p = 123; // expected-note {{assignment to dereferenced null
pointer}}
+return *p = 123; // expected-note {{read of dereferenced null pointer}}
AaronB
@@ -17563,6 +17573,16 @@ Sema::ActOnTag(Scope *S, unsigned TagSpec, TagUseKind
TUK, SourceLocation KWLoc,
UPPC_FixedUnderlyingType))
EnumUnderlying = Context.IntTy.getTypePtr();
+ // If the underlying type is atomic, we n
https://github.com/AaronBallman updated
https://github.com/llvm/llvm-project/pull/147802
>From e65fa6bdd251ceef52e11ff8ee856058e8e3c47a Mon Sep 17 00:00:00 2001
From: Aaron Ballman
Date: Wed, 9 Jul 2025 14:40:00 -0400
Subject: [PATCH 1/4] [C23] Accept an _Atomic underlying type
The underlying
@@ -59,7 +59,7 @@ constexpr bool test() {
{
// bidi
-int buffer[2] = {1, 2};
+int buffer[3] = {1, 2, 3};
AaronBallman wrote:
I'd think that as well, but the fact that it passed when it should fail means
we should double-check. :-D I don't have
AaronBallman wrote:
> If a function has a deferred diagnostic, it should prevent codegen of that
> function, yes.
Deferred errors only, though, right? Do we know if there are any cases where we
defer the diagnostic because we may later decide it's *not* an error and thus
codegen would be fine
@@ -59,7 +59,7 @@ constexpr bool test() {
{
// bidi
-int buffer[2] = {1, 2};
+int buffer[3] = {1, 2, 3};
AaronBallman wrote:
Thanks! I kind of figured that was the case, but it wasn't clear whether the
test should change like this or not.
@ld
https://github.com/AaronBallman approved this pull request.
I think this is correct; if it turns out to be an issue for HLSL, we can cross
that bridge when we come to it.
https://github.com/llvm/llvm-project/pull/147306
___
cfe-commits mailing list
cf
AaronBallman wrote:
> I THINK this is right, but we also need to have a codegen test to make sure
> we don't try to do goofiness with these.
I was thinking the ast-dump test sufficed because it shows that we set the
underlying type to non-atomic in the AST. But I can certainly add a codegen
t
@@ -17152,6 +17152,13 @@ bool Sema::CheckEnumUnderlyingType(TypeSourceInfo *TI)
{
SourceLocation UnderlyingLoc = TI->getTypeLoc().getBeginLoc();
QualType T = TI->getType();
+ // C++0x 7.2p2: The type-specifier-seq of an enum-base shall name an
+ // integral type; any cv
@@ -17563,6 +17573,16 @@ Sema::ActOnTag(Scope *S, unsigned TagSpec, TagUseKind
TUK, SourceLocation KWLoc,
UPPC_FixedUnderlyingType))
EnumUnderlying = Context.IntTy.getTypePtr();
+ // If the underlying type is atomic, we n
@@ -547,6 +547,15 @@ static void DoEmitAvailabilityWarning(Sema &S,
AvailabilityResult K,
return;
}
case AR_Deprecated:
+// Suppress -Wdeprecated-declarations in purely implicit special-member
functions.
+if (auto *MD = dyn_cast_if_present(S.getCurFunctionDecl
https://github.com/AaronBallman requested changes to this pull request.
Actually, the changes still LGTM, but let's hold off on landing the changes
until we give WG21 a chance to weigh in. It's possible we'll end up converging
and not need to have different behaviors.
https://github.com/llvm/l
https://github.com/AaronBallman closed
https://github.com/llvm/llvm-project/pull/147285
___
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/141133
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
AaronBallman wrote:
> Hi all! So given the discussion above and that @erichkeane also okayed this,
> can we finally proceed with this PR? I'd like to note that after discussing
> it for the past month and a half, it still seems like we have no idea what
> the ideal solution to the more-general
AaronBallman wrote:
> My understanding is that "recoverable" in this context means we can actually
> generate sensible IR for the construct. So no errors, except for warnings
> promoted to errors (or certain errors which don't impact IRGen/CFG analysis).
> And if that isn't what isUnrecoverabl
AaronBallman wrote:
> LGTM, but it would be great to get someone familiar with MS side of things to
> take a look.
>
> @rnk is there anything else we need to worry about?
@rnk is out on vacation, so I'd say we're good to go.
https://github.com/llvm/llvm-project/pull/146620
___
https://github.com/AaronBallman approved this pull request.
LGTM!
https://github.com/llvm/llvm-project/pull/146620
___
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/147308
___
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/147275
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -4111,7 +4111,10 @@ static ActionResult
getPatternForClassTemplateSpecialization(
if (Ambiguous) {
// Partial ordering did not produce a clear winner. Complain.
Inst.Clear();
- ClassTemplateSpec->setInvalidDecl();
+
+ if (!S.isS
https://github.com/AaronBallman commented:
Awesome! We just need @xlauko to explicitly approve and then we're good to go!
https://github.com/llvm/llvm-project/pull/147365
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cg
https://github.com/AaronBallman approved this pull request.
LGTM!
https://github.com/llvm/llvm-project/pull/147503
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -477,3 +477,10 @@ namespace P2361 {
}
alignas(int) struct AlignAsAttribute {}; // expected-error {{misplaced
attributes; expected attributes here}}
+
+namespace GH147217 {
+ [[clang::annotate(#)]] void a();// expected-error {{'#' is not allowed
in an attribute argume
@@ -678,6 +678,8 @@ Improvements to Clang's diagnostics
- Clang now accepts ``@tparam`` comments on variable template partial
specializations. (#GH144775)
+- Clang now rejects ``#`` operators in attribute argument lists. (#GH147217)
AaronBallman wrote:
```s
@@ -477,3 +477,8 @@ namespace P2361 {
}
alignas(int) struct AlignAsAttribute {}; // expected-error {{misplaced
attributes; expected attributes here}}
+
+namespace GH147217 {
+ [[clang::annotate(#)]] void a(); // expected-error {{'#' is not allowed
in attribute argument
AaronBallman wrote:
> Thansk for the explainer! That gives me something to test, I will try a
> cross-compile with GCC and see if I can reproduce it locally.
>
> > It's not immediately obvious to me why the host compiler would make any
> > difference on this particular PR ...
>
> We are chang
https://github.com/AaronBallman approved this pull request.
LGTM, thank you!
https://github.com/llvm/llvm-project/pull/144619
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
AaronBallman wrote:
> This patch fixes an issue where Microsoft-specific layout attributes, such as
> __declspec(empty_bases), were ignored during CUDA/HIP device compilation on a
> Windows host. This caused a critical memory layout mismatch between host and
> device objects, breaking librarie
AaronBallman wrote:
> No idea why it blew up on that particular s390x buildbot. @AaronBallman Any
> ideas?
Err, I have no idea, I've never seen that sort of behavior before!
https://github.com/llvm/llvm-project/pull/146844
___
cfe-commits mailing lis
@@ -747,6 +747,10 @@ Bug Fixes in This Version
- Fixed an infinite recursion when checking constexpr destructors. (#GH141789)
- Fixed a crash when a malformed using declaration appears in a ``constexpr``
function. (#GH144264)
- Fixed a bug when use unicode character name in ma
@@ -276,6 +276,10 @@ def err_expected_while : Error<"expected 'while' in
do/while loop">;
def err_expected_semi_after_stmt : Error<"expected ';' after %0 statement">;
def err_expected_semi_after_expr : Error<"expected ';' after expression">;
+def warn_expected_stmt_before_sem
@@ -830,6 +830,8 @@ def err_ms_property_expected_comma_or_rparen : Error<
"expected ',' or ')' at end of property accessor list">;
def err_ms_property_initializer : Error<
"property declaration cannot have a default member initializer">;
+def err_invalid_attribute_argument
@@ -488,6 +488,13 @@ unsigned Parser::ParseAttributeArgsCommon(
bool AttributeHasVariadicIdentifierArg =
attributeHasVariadicIdentifierArg(*AttrName, Form.getSyntax(),
ScopeName);
+ if (Tok.is(tok::hash) || Tok.is(tok::hashhash)) {
AaronBallman wrote
https://github.com/AaronBallman commented:
I think the old code was not handling Microsoft attributes and I think the new
code is also not handling Microsoft attributes, just in a different way.
AIUI, Microsoft attributes are deprecated (https://godbolt.org/z/Ma45KKMvG) and
only used on a decl
https://github.com/AaronBallman approved this pull request.
LGTM!
https://github.com/llvm/llvm-project/pull/143520
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
AaronBallman wrote:
> In some tentative parses, we would always consider `[` as the start of an
> attribute - only `[[` should be.
>
> Fixes #63880
It is the start of an attribute: Microsoft-style attributes are single bracket
rather than double bracket.
https://github.com/llvm/llvm-project/
@@ -7757,7 +7762,9 @@ void Sema::AddMethodCandidate(
Candidate.Viable = true;
unsigned FirstConvIdx = PO == OverloadCandidateParamOrder::Reversed ? 1 : 0;
- if (ObjectType.isNull())
+ if (IgnoreExplicitObject)
+;
AaronBallman wrote:
How bad is it to
@@ -7876,6 +7883,7 @@ static void AddMethodTemplateCandidateImmediately(
// function template are combined with the set of non-template candidate
// functions.
TemplateDeductionInfo Info(CandidateSet.getLocation());
+ auto Method = cast(MethodTmpl->getTemplatedDecl()
https://github.com/AaronBallman approved this pull request.
The changes look correct to me, but I added Eli and Alexey for some other
opinions to be sure.
https://github.com/llvm/llvm-project/pull/147163
___
cfe-commits mailing list
cfe-commits@lists.
@@ -291,6 +291,14 @@ void DeclInfo::fill() {
TemplateParameters = CTPSD->getTemplateParameters();
break;
}
+ case Decl::VarTemplatePartialSpecialization: {
+const VarTemplatePartialSpecializationDecl *VTPSD =
AaronBallman wrote:
```suggestion
https://github.com/AaronBallman approved this pull request.
LGTM, with a small nit. (Feel free to land once addressed, additional review
not required.)
https://github.com/llvm/llvm-project/pull/147219
___
cfe-commits mailing list
cfe-commits@lists.llv
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/147219
___
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/147284
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
AaronBallman wrote:
> Can we merge this with private email address?
Community policy is to have public email addresses:
https://llvm.org/docs/DeveloperPolicy.html#email-addresses
https://github.com/llvm/llvm-project/pull/146433
___
cfe-commits mailin
https://github.com/AaronBallman updated
https://github.com/llvm/llvm-project/pull/147284
>From 926fd7ce1264bd263a9fd46409ec7cc8e2d2db27 Mon Sep 17 00:00:00 2001
From: Aaron Ballman
Date: Mon, 7 Jul 2025 07:47:54 -0400
Subject: [PATCH 1/3] [clang-cl] Support /stdc:latest
cl.exe has /stdc:latest
AaronBallman wrote:
> > You've got the same typo (?) in a bunch of places. You have `/stdc:latest`
> > instead of `/std:clatest`. Same for `/std:c++latest`.
>
> Good catch! Sheesh, fingers. Work!
Those are all addressed. This is what I get for typing `__STDC_*` as often as I
do. :-D
https://
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/147284
___
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/147284
___
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/147284
>From 926fd7ce1264bd263a9fd46409ec7cc8e2d2db27 Mon Sep 17 00:00:00 2001
From: Aaron Ballman
Date: Mon, 7 Jul 2025 07:47:54 -0400
Subject: [PATCH 1/2] [clang-cl] Support /stdc:latest
cl.exe has /stdc:latest
https://github.com/AaronBallman approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/147286
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
AaronBallman wrote:
> You've got the same typo (?) in a bunch of places. You have `/stdc:latest`
> instead of `/std:clatest`. Same for `/std:c++latest`.
Good catch! Sheesh, fingers. Work!
https://github.com/llvm/llvm-project/pull/147284
___
cfe-commi
@@ -1450,7 +1450,6 @@ def MicrosoftAnonTag : DiagGroup<"microsoft-anon-tag">;
def MicrosoftCommentPaste : DiagGroup<"microsoft-comment-paste">;
def MicrosoftEndOfFile : DiagGroup<"microsoft-end-of-file">;
def MicrosoftInaccessibleBase : DiagGroup<"microsoft-inaccessible-base">;
@@ -1450,7 +1450,6 @@ def MicrosoftAnonTag : DiagGroup<"microsoft-anon-tag">;
def MicrosoftCommentPaste : DiagGroup<"microsoft-comment-paste">;
def MicrosoftEndOfFile : DiagGroup<"microsoft-end-of-file">;
def MicrosoftInaccessibleBase : DiagGroup<"microsoft-inaccessible-base">;
https://github.com/AaronBallman approved this pull request.
LGTM! My cleverness didn't work out, alas. :-D
https://github.com/llvm/llvm-project/pull/147030
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/l
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/147030
___
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/147284
cl.exe has /stdc:latest, analogous to /stdc++:latest, which sets the language
mode to the latest standard. For C, that's C23. This adds support for the
option.
Fixes #147233
>From 926fd7ce1264bd263a9fd46
https://github.com/AaronBallman closed
https://github.com/llvm/llvm-project/pull/146394
___
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/146394
>From 94cd71d65fe27cdde0c39416a0e2e709af98ed0c Mon Sep 17 00:00:00 2001
From: Aaron Ballman
Date: Mon, 30 Jun 2025 13:26:57 -0400
Subject: [PATCH 1/7] [C23] Fix typeof handling in enum declarations
We have
AaronBallman wrote:
> > let's handle C++ separately to keep the patch reasonable?
>
> ~What about Objective-C then?~
>
> ```c
> void f() {
> ^ typeof((void)0) {}; // Ok
> ^ typeof(void) {};// Error but should probably be ok
> }
> ```
>
> But yeah, doing all of that in this pr might
AaronBallman wrote:
> Since we’re on to C++ support now, here’s one more fun case:
>
> ```c++
> class A {}; A a;
> class B : typeof(A) {};
> class C : typeof(a) {};
> ```
Good test cases, but let's handle C++ separately to keep the patch reasonable?
https://github.com/llvm/llvm-project/pull/1
AaronBallman wrote:
> > > ```c++
> > > typeof(int){} x; // Probably parsed as typeof(int{})
> > > ```
> >
> >
> > GCC reject this https://godbolt.org/z/YEdnGh8T5
>
> Yeah, I think there are a few different issues. 1) we should not accept in C.
> 2) C++ has its own issue in that we accept `typ
AaronBallman wrote:
> > ```c++
> > typeof(int){} x; // Probably parsed as typeof(int{})
> > ```
>
> GCC reject this https://godbolt.org/z/YEdnGh8T5
Yeah, I think there are a few different issues. 1) we should not accept in C.
2) C++ has its own issue in that we accept `typeof` there despite th
AaronBallman wrote:
> > > > ```c++
> > > > typeof(int){} x; // Probably parsed as typeof(int{})
> > > > ```
> > >
> > >
> > > Actually, I’m not sure what we think this is supposed to be; I haven’t
> > > checked.
> >
> >
> > Actually, that’s just a compound literal; I forgot we supported thos
AaronBallman wrote:
Windows failures are unrelated, they're a CI issue tracked by
https://github.com/llvm/llvm-project/issues/145703
https://github.com/llvm/llvm-project/pull/146394
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists
https://github.com/AaronBallman updated
https://github.com/llvm/llvm-project/pull/146394
>From 94cd71d65fe27cdde0c39416a0e2e709af98ed0c Mon Sep 17 00:00:00 2001
From: Aaron Ballman
Date: Mon, 30 Jun 2025 13:26:57 -0400
Subject: [PATCH 1/6] [C23] Fix typeof handling in enum declarations
We have
https://github.com/AaronBallman updated
https://github.com/llvm/llvm-project/pull/146394
>From 94cd71d65fe27cdde0c39416a0e2e709af98ed0c Mon Sep 17 00:00:00 2001
From: Aaron Ballman
Date: Mon, 30 Jun 2025 13:26:57 -0400
Subject: [PATCH 1/5] [C23] Fix typeof handling in enum declarations
We have
AaronBallman wrote:
> My expectation would be that if I specify a header filter I'm not going to
> use weird paths like a/b/../foo.h, but just a/foo.h because that is where
> foo.h lives.
What about symlinks though? Would you expect that passing `path/to/file` fails
because `path` is a symlin
AaronBallman wrote:
> > > ```c++
> > > typeof(int){} x; // Probably parsed as typeof(int{})
> > > ```
> >
> >
> > Actually, I’m not sure what we think this is supposed to be; I haven’t
> > checked.
>
> Actually, that’s just a compound literal; I forgot we supported those in C++.
It's a reall
https://github.com/AaronBallman updated
https://github.com/llvm/llvm-project/pull/146394
>From 94cd71d65fe27cdde0c39416a0e2e709af98ed0c Mon Sep 17 00:00:00 2001
From: Aaron Ballman
Date: Mon, 30 Jun 2025 13:26:57 -0400
Subject: [PATCH 1/4] [C23] Fix typeof handling in enum declarations
We have
@@ -506,7 +506,15 @@ void clang::FormatASTNodeDiagnosticArgument(
case DiagnosticsEngine::ak_attr: {
const Attr *At = reinterpret_cast(Val);
assert(At && "Received null Attr object!");
- OS << '\'' << At->getSpelling() << '\'';
+
+ OS << '\'';
+ i
@@ -2850,7 +2870,8 @@ Parser::ParseParenExpression(ParenParseOption &ExprType,
bool stopIfCastExpr,
isFoldOperator(NextToken().getKind())) {
ExprType = ParenParseOption::FoldExpr;
return ParseFoldExpression(ExprResult(), T);
- } else if (isTypeCast) {
+
@@ -4210,6 +4215,7 @@ class Parser : public CodeCompletionHandler {
/// \endverbatim
ExprResult ParseParenExpression(ParenParseOption &ExprType,
bool stopIfCastExpr, bool isTypeCast,
+ bool ParenKnownToBeNon
https://github.com/AaronBallman updated
https://github.com/llvm/llvm-project/pull/146394
>From 94cd71d65fe27cdde0c39416a0e2e709af98ed0c Mon Sep 17 00:00:00 2001
From: Aaron Ballman
Date: Mon, 30 Jun 2025 13:26:57 -0400
Subject: [PATCH 1/3] [C23] Fix typeof handling in enum declarations
We have
AaronBallman wrote:
> Ok, looks like the clang-tidy test failure is related to the `-header-filter`
> option:
>
> ```c++
> // Check that `-header-filter` operates on the same file paths as paths in
> // diagnostics printed by ClangTidy.
> #include "dir1/dir2/../header_alias.h"
> // CHECK_HEADER
https://github.com/AaronBallman updated
https://github.com/llvm/llvm-project/pull/146394
>From 94cd71d65fe27cdde0c39416a0e2e709af98ed0c Mon Sep 17 00:00:00 2001
From: Aaron Ballman
Date: Mon, 30 Jun 2025 13:26:57 -0400
Subject: [PATCH 1/2] [C23] Fix typeof handling in enum declarations
We have
1 - 100 of 3292 matches
Mail list logo
