[clang] [clang] MangledSymbol: remove pointless copy of vector (PR #90012)

AaronBallman wrote: > Thank you everyone for the reviews! Thank you for the improvement! https://github.com/llvm/llvm-project/pull/90012 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[clang] [clang-tools-extra] [Clang] Unify interface for accessing template arguments as written for class/variable template specializations (PR #81642)

@@ -111,6 +111,13 @@ Clang Frontend Potentially Breaking Changes $ clang --target= -print-target-triple +- The ``getTypeAsWritten`` member function has been removed from ``ClassTemplateSpecializationDecl`` and + ``VarTemplateSpecializationDecl``, and a new member

[clang] [clang] MangledSymbol: remove pointless copy of vector (PR #90012)

https://github.com/AaronBallman closed https://github.com/llvm/llvm-project/pull/90012 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] MangledSymbol: remove pointless copy of vector (PR #90012)

https://github.com/AaronBallman updated https://github.com/llvm/llvm-project/pull/90012 >From 9007597af4f138d2744405bb7980fce4555d7508 Mon Sep 17 00:00:00 2001 From: Andrew Sukach Date: Wed, 24 Apr 2024 22:50:50 -0400 Subject: [PATCH 1/3] [clang] MangledSymbol: remove pointless copy of vector

[clang] [clang] MangledSymbol: remove pointless copy of vector (PR #90012)

https://github.com/AaronBallman approved this pull request. LGTM! https://github.com/llvm/llvm-project/pull/90012 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [Clang] Unify interface for accessing template arguments as written for class/variable template specializations (PR #81642)

@@ -111,6 +111,13 @@ Clang Frontend Potentially Breaking Changes $ clang --target= -print-target-triple +- The ``getTypeAsWritten`` member function has been removed from ``ClassTemplateSpecializationDecl`` and + ``VarTemplateSpecializationDecl``, and a new member

[clang] [clang-tools-extra] [Clang] Unify interface for accessing template arguments as written for class/variable template specializations (PR #81642)

https://github.com/AaronBallman edited https://github.com/llvm/llvm-project/pull/81642 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [Clang] Unify interface for accessing template arguments as written for class/variable template specializations (PR #81642)

https://github.com/AaronBallman approved this pull request. LGTM aside from a possible nit with the release note (I don't need to re-review). https://github.com/llvm/llvm-project/pull/81642 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[clang] [CIR] Build out AST consumer patterns to reach the entry point into CIRGen (PR #91007)

@@ -0,0 +1,88 @@ +//===--- CIRGenAction.cpp - LLVM Code generation Frontend Action -===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier:

[clang] [CIR] Build out AST consumer patterns to reach the entry point into CIRGen (PR #91007)

@@ -0,0 +1,88 @@ +//===--- CIRGenAction.cpp - LLVM Code generation Frontend Action -===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier:

[clang] [CIR] Build out AST consumer patterns to reach the entry point into CIRGen (PR #91007)

@@ -0,0 +1,59 @@ +//===- CIRGenerator.h - CIR Generation from Clang AST -===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier:

[clang] [CIR] Build out AST consumer patterns to reach the entry point into CIRGen (PR #91007)

@@ -0,0 +1,59 @@ +//===- CIRGenerator.h - CIR Generation from Clang AST -===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier:

[clang] [CIR] Build out AST consumer patterns to reach the entry point into CIRGen (PR #91007)

@@ -0,0 +1,46 @@ +//===--- CIRGenerator.cpp - Emit CIR from ASTs ===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier:

[clang] [CIR] Build out AST consumer patterns to reach the entry point into CIRGen (PR #91007)

@@ -0,0 +1,61 @@ +//===--- CIRGenModule.h - Per-Module state for CIR gen --*- C++ -*-===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier:

[clang] [CIR] Build out AST consumer patterns to reach the entry point into CIRGen (PR #91007)

@@ -0,0 +1,35 @@ +//===- CIRGenModule.cpp - Per-Module state for CIR generation -===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier:

[clang] [CIR] Build out AST consumer patterns to reach the entry point into CIRGen (PR #91007)

@@ -42,6 +47,14 @@ CreateFrontendBaseAction(CompilerInstance ) { StringRef Action("unknown"); (void)Action; + auto UseCIR = CI.getFrontendOpts().UseClangIRPipeline; AaronBallman wrote: Please follow the community conventions in this case because this is

[clang] [CIR] Build out AST consumer patterns to reach the entry point into CIRGen (PR #91007)

@@ -0,0 +1,27 @@ +//===--- CIRGenTypeCache.h - Commonly used LLVM types and info -*- C++ --*-===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier:

[clang] [CIR] Build out AST consumer patterns to reach the entry point into CIRGen (PR #91007)

@@ -0,0 +1,61 @@ +//===--- CIRGenModule.h - Per-Module state for CIR gen --*- C++ -*-===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier:

[clang] [CIR] Build out AST consumer patterns to reach the entry point into CIRGen (PR #91007)

@@ -0,0 +1,59 @@ +//===- CIRGenerator.h - CIR Generation from Clang AST -===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier:

[clang] [CIR] Build out AST consumer patterns to reach the entry point into CIRGen (PR #91007)

@@ -0,0 +1,59 @@ +//===- CIRGenerator.h - CIR Generation from Clang AST -===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier:

[clang] [clang-tools-extra] [Clang] Unify interface for accessing template arguments as written for class/variable template specializations (PR #81642)

@@ -764,9 +764,9 @@ AST_POLYMORPHIC_MATCHER(isImplicit, return Node.isImplicit(); } -/// Matches classTemplateSpecializations, templateSpecializationType and -/// functionDecl that have at least one TemplateArgument matching the given -/// InnerMatcher. +/// Matches

[clang] [clang-tools-extra] [Clang] Unify interface for accessing template arguments as written for class/variable template specializations (PR #81642)

@@ -4075,9 +4076,8 @@ AST_POLYMORPHIC_MATCHER_P( AST_POLYMORPHIC_SUPPORTED_TYPES( BlockDecl, CXXBaseSpecifier, CXXCtorInitializer, CXXFunctionalCastExpr, CXXNewExpr, CXXTemporaryObjectExpr, CXXUnresolvedConstructExpr, -

[clang] [Clang][Comments] Support for parsing headers in Doxygen \par commands (PR #91100)

@@ -149,6 +149,63 @@ class TextTokenRetokenizer { addToken(); } + /// Check if this line starts with @par or \par + bool startsWithParCommand() { +unsigned Offset = 1; + +/// Skip all whitespace characters at the beginning. +/// This needs to backtrack

[clang] [Clang][Comments] Support for parsing headers in Doxygen \par commands (PR #91100)

@@ -304,6 +361,23 @@ Parser::parseCommandArgs(TextTokenRetokenizer , unsigned NumArgs) { return llvm::ArrayRef(Args, ParsedArgs); } +ArrayRef +Parser::parseParCommandArgs(TextTokenRetokenizer , +unsigned NumArgs) { AaronBallman

[clang] [Clang][Comments] Support for parsing headers in Doxygen \par commands (PR #91100)

@@ -149,6 +149,63 @@ class TextTokenRetokenizer { addToken(); } + /// Check if this line starts with @par or \par + bool startsWithParCommand() { +unsigned Offset = 1; + +/// Skip all whitespace characters at the beginning. +/// This needs to backtrack

[clang] [Clang][Comments] Support for parsing headers in Doxygen \par commands (PR #91100)

@@ -149,6 +149,63 @@ class TextTokenRetokenizer { addToken(); } + /// Check if this line starts with @par or \par + bool startsWithParCommand() { +unsigned Offset = 1; + +/// Skip all whitespace characters at the beginning. +/// This needs to backtrack

[clang] Revise the modules document for clarity (PR #90237)

https://github.com/AaronBallman updated https://github.com/llvm/llvm-project/pull/90237 >From a75aa14fcad6f346a3073ae88e91fa890e803422 Mon Sep 17 00:00:00 2001 From: Aaron Ballman Date: Fri, 26 Apr 2024 13:12:51 -0400 Subject: [PATCH 1/2] Revise the modules document for clarity The intention

[clang] Revise the modules document for clarity (PR #90237)

https://github.com/AaronBallman created https://github.com/llvm/llvm-project/pull/90237 The intention isn't to add or change the information provided, but to improve clarity through some grammar fixes, improvements to the markdown, and so forth. >From a75aa14fcad6f346a3073ae88e91fa890e803422

[clang] [clang-tools-extra] [libcxx] [C++17] Support __GCC_[CON|DE]STRUCTIVE_SIZE (PR #89446)

https://github.com/AaronBallman closed https://github.com/llvm/llvm-project/pull/89446 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [libcxx] [C++17] Support __GCC_[CON|DE]STRUCTIVE_SIZE (PR #89446)

@@ -5571,3 +5571,19 @@ but the expression has no runtime effects. Type- and value-dependent expressions are not supported yet. This facility is designed to aid with testing name lookup machinery. + +Predefined Macros += + +`__GCC_DESTRUCTIVE_SIZE` and

[clang] [clang-tools-extra] [libcxx] [C++17] Support __GCC_[CON|DE]STRUCTIVE_SIZE (PR #89446)

https://github.com/AaronBallman updated https://github.com/llvm/llvm-project/pull/89446 >From 9d394964d3d04c9d7ffd753751f2aaa3a96c9480 Mon Sep 17 00:00:00 2001 From: Aaron Ballman Date: Fri, 19 Apr 2024 15:56:54 -0400 Subject: [PATCH 01/12] [C++17] Support __GCC_[CON|DE]STRUCTIVE_SIZE These

[clang] [clang-tools-extra] [libcxx] [C++17] Support __GCC_[CON|DE]STRUCTIVE_SIZE (PR #89446)

AaronBallman wrote: I think this resolves all the outstanding issues. I plan to land these changes sometime today unless I hear otherwise (we can also address additional concerns post-commit). https://github.com/llvm/llvm-project/pull/89446 ___

[clang] [clang-tools-extra] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)

https://github.com/AaronBallman commented: I don't want this to be considered a comment which blocks the changes if others feel strongly in favor of them, but I'm not really convinced we should do this. The number of problems this patch will solve is approximately zero but the number of

[clang] [clang][NFC] Reformat suspicious condition (PR #89923)

AaronBallman wrote: > I see that the build has failed - what do I need to do to fix this? That build failure looks unrelated to your changes, I think it just got caught in a bad state. You can try pushing no changes to the branch to kick off a new build just to be sure, though.

[clang] [clang-tools-extra] [PAC][clang] Define `PointerAuthQualifier` and `PointerAuthenticationMode` (PR #84384)

https://github.com/AaronBallman approved this pull request. LGTM, thank you for the improvement for performance! https://github.com/llvm/llvm-project/pull/84384 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[clang] [libcxx] [C++17] Support __GCC_[CON|DE]STRUCTIVE_SIZE (PR #89446)

AaronBallman wrote: > I'd rather keep the libc++ tests green while landing this PR. I tried > something out, let's see if that works. It looks like some further adjustments may be needed as some stage1 builders are failing: ``` # .---command stderr # |

[clang] [Clang] Don't diagnose VLA for `-std=gnu++*` by default (PR #89943)

AaronBallman wrote: > > This was discussed in this RFC: > > https://discourse.llvm.org/t/rfc-diagnosing-use-of-vlas-in-c/73109 and our > > decision to move forward with that is independent of what GCC does. > > I saw that discussion, but I do miss where it has been agreed to diverge from >

[clang] [Clang] Don't diagnose VLA for `-std=gnu++*` by default (PR #89943)

https://github.com/AaronBallman requested changes to this pull request. This was discussed in this RFC: https://discourse.llvm.org/t/rfc-diagnosing-use-of-vlas-in-c/73109 and our decision to move forward with that is independent of what GCC does. Without more justification for walking this

[clang] [libcxx] [C++17] Support __GCC_[CON|DE]STRUCTIVE_SIZE (PR #89446)

AaronBallman wrote: > I don't think this feature warrants deviating from our policy that on-by > default warnings should be actionable and have a low false-positive rate, nor > the complexity to actually produce the warning. Specific to this point, what concerns me is that there are uses

[clang] [libcxx] [C++17] Support __GCC_[CON|DE]STRUCTIVE_SIZE (PR #89446)

@@ -1792,6 +1792,11 @@ class TargetInfo : public TransferrableTargetInfo, /// Whether to support HIP image/texture API's. virtual bool hasHIPImageSupport() const { return true; } + /// The minimum offset between two objects to avoid false sharing. + virtual unsigned

[clang] [libcxx] [C++17] Support __GCC_[CON|DE]STRUCTIVE_SIZE (PR #89446)

@@ -1792,6 +1792,11 @@ class TargetInfo : public TransferrableTargetInfo, /// Whether to support HIP image/texture API's. virtual bool hasHIPImageSupport() const { return true; } + /// The minimum offset between two objects to avoid false sharing.

[clang] [libcxx] [C++17] Support __GCC_[CON|DE]STRUCTIVE_SIZE (PR #89446)

@@ -89,6 +89,19 @@ sections with improvements to Clang's support for those languages. C++ Language Changes +C++17 Feature Support +^ +- Clang now exposes ``__GCC_DESTRUCTIVE_SIZE`` and ``__GCC_CONSTRUCTIVE_SIZE`` + predefined macros

[clang] [libcxx] [C++17] Support __GCC_[CON|DE]STRUCTIVE_SIZE (PR #89446)

@@ -89,6 +89,19 @@ sections with improvements to Clang's support for those languages. C++ Language Changes +C++17 Feature Support +^ +- Clang now exposes ``__GCC_DESTRUCTIVE_SIZE`` and ``__GCC_CONSTRUCTIVE_SIZE`` + predefined macros

[clang] [Attributes] Support Attributes being declared as supporting an experimental late parsing mode "extension" (PR #88596)

@@ -592,6 +592,48 @@ class AttrSubjectMatcherAggregateRule { def SubjectMatcherForNamed : AttrSubjectMatcherAggregateRule; +// Late Attribute parsing mode enum +class LateAttrParseKind { + int Kind = val; +} + +// Never late parsed +def LateAttrParseNever :

[clang] [Attributes] Support Attributes being declared as supporting an experimental late parsing mode "extension" (PR #88596)

@@ -220,8 +230,28 @@ void Parser::ParseGNUAttributes(ParsedAttributes , continue; } + bool LateParse = false; + if (!LateAttrs) +LateParse = false; + else { AaronBallman wrote: Can remove a level of indentation here by

[clang] [Attributes] Support Attributes being declared as supporting an experimental late parsing mode "extension" (PR #88596)

@@ -1822,28 +1822,100 @@ void WriteSemanticSpellingSwitch(const std::string , OS << " }\n"; } +enum class LateAttrParseKind { Never = 0, Standard = 1, ExperimentalExt = 2 }; + +static LateAttrParseKind getLateAttrParseKind(const Record *Attr) { + // This function

[clang] [Attributes] Support Attributes being declared as supporting an experimental late parsing mode "extension" (PR #88596)

@@ -1822,28 +1822,100 @@ void WriteSemanticSpellingSwitch(const std::string , OS << " }\n"; } +enum class LateAttrParseKind { Never = 0, Standard = 1, ExperimentalExt = 2 }; AaronBallman wrote: ```suggestion // Note: these values need to match the values

[clang] [Attributes] Support Attributes being declared as supporting an experimental late parsing mode "extension" (PR #88596)

@@ -220,8 +230,28 @@ void Parser::ParseGNUAttributes(ParsedAttributes , continue; } + bool LateParse = false; + if (!LateAttrs) +LateParse = false; + else { +if (LateAttrs->lateAttrParseExperimentalExtOnly()) { + // The

[clang] [Attributes] Support Attributes being declared as supporting an experimental late parsing mode "extension" (PR #88596)

@@ -1822,28 +1822,100 @@ void WriteSemanticSpellingSwitch(const std::string , OS << " }\n"; } +enum class LateAttrParseKind { Never = 0, Standard = 1, ExperimentalExt = 2 }; + +static LateAttrParseKind getLateAttrParseKind(const Record *Attr) { + // This function

[clang] [Attributes] Support Attributes being declared as supporting an experimental late parsing mode "extension" (PR #88596)

@@ -592,6 +592,48 @@ class AttrSubjectMatcherAggregateRule { def SubjectMatcherForNamed : AttrSubjectMatcherAggregateRule; +// Late Attribute parsing mode enum +class LateAttrParseKind { + int Kind = val; +} AaronBallman wrote: ```suggestion //

[clang] [Attributes] Support Attributes being declared as supporting an experimental late parsing mode "extension" (PR #88596)

@@ -592,6 +592,48 @@ class AttrSubjectMatcherAggregateRule { def SubjectMatcherForNamed : AttrSubjectMatcherAggregateRule; +// Late Attribute parsing mode enum +class LateAttrParseKind { + int Kind = val; +} + +// Never late parsed +def LateAttrParseNever :

[clang] [Attributes] Support Attributes being declared as supporting an experimental late parsing mode "extension" (PR #88596)

https://github.com/AaronBallman commented: We should probably add a release note to tell users about the new command line option, unless you think it makes more sense to do so after something uses `LateAttrParseExperimentalExt`? One concern I have is that nothing is testing the new parsing

[clang] [Attributes] Support Attributes being declared as supporting an experimental late parsing mode "extension" (PR #88596)

https://github.com/AaronBallman edited https://github.com/llvm/llvm-project/pull/88596 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [C++23] [CLANG] Adding C++23 constexpr math functions: fmin and frexp. (PR #88978)

@@ -2922,7 +2922,7 @@ static bool handleFloatFloatBinOp(EvalInfo , const BinaryOperator *E, // If during the evaluation of an expression, the result is not // mathematically defined [...], the behavior is undefined. // FIXME: C++ rules require us to not conform to

[clang] [C++23] [CLANG] Adding C++23 constexpr math functions: fmin and frexp. (PR #88978)

@@ -2922,7 +2922,7 @@ static bool handleFloatFloatBinOp(EvalInfo , const BinaryOperator *E, // If during the evaluation of an expression, the result is not // mathematically defined [...], the behavior is undefined. // FIXME: C++ rules require us to not conform to

[clang] [Clang][Parser] Don't always destroy template annotations at the end of a declaration (PR #89494)

AaronBallman wrote: On reflection, I am still happy enough with this approach. @cor3ntin's observation that we could remove the call to `MaybeDestroyTemplateIds()` so that we only destroy at the end of top-level decls and member specifications would work, but I think there arern was largely

[clang] [Clang][Parser] Don't always destroy template annotations at the end of a declaration (PR #89494)

AaronBallman wrote: > Oops. I thought there was some latency between clicking the merge button and > your latest comment. Should I revert? No worries, I should have hit `Request Changes` instead of `Comment`. :-) No need to revert yet. https://github.com/llvm/llvm-project/pull/89494

[clang] [Clang][Parser] Don't always destroy template annotations at the end of a declaration (PR #89494)

https://github.com/AaronBallman commented: Oops, I misunderstood what @cor3ntin was saying. One moment while I re-think now that I have understood his point better. https://github.com/llvm/llvm-project/pull/89494 ___ cfe-commits mailing list

[clang] [C++17] Support __GCC_[CON|DE]STRUCTIVE_SIZE (PR #89446)

AaronBallman wrote: Precommit CI is currently failing on libc++ tests that are impacted by this change; should I solve those as part of this patch or are you okay with fixing those after this patch lands? (Or would you like to push a fix to this branch?)

[clang] [Clang][Parser] Don't always destroy template annotations at the end of a declaration (PR #89494)

https://github.com/AaronBallman approved this pull request. LGTM! https://github.com/llvm/llvm-project/pull/89494 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] pointer to member with qualified-id enclosed in parentheses in unevaluated context should be invalid (PR #89713)

@@ -14644,6 +14644,17 @@ QualType Sema::CheckAddressOfOperand(ExprResult , SourceLocation OpLoc) { return QualType(); } + // C++11 [expr.unary.op] p4: + // A pointer to member is only formed when an explicit & is used and + //

[clang] [clang] pointer to member with qualified-id enclosed in parentheses in unevaluated context should be invalid (PR #89713)

https://github.com/AaronBallman edited https://github.com/llvm/llvm-project/pull/89713 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] pointer to member with qualified-id enclosed in parentheses in unevaluated context should be invalid (PR #89713)

https://github.com/AaronBallman commented: Thank you for the fix! You should also add a release note to clang/docs/ReleaseNotes.rst so that users know about the improvement. https://github.com/llvm/llvm-project/pull/89713 ___ cfe-commits mailing list

[clang] [clang] pointer to member with qualified-id enclosed in parentheses in unevaluated context should be invalid (PR #89713)

https://github.com/AaronBallman edited https://github.com/llvm/llvm-project/pull/89713 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [C++17] Support __GCC_[CON|DE]STRUCTIVE_SIZE (PR #89446)

AaronBallman wrote: Here are the values that I found for GCC that don't match the defaults. |Platform|Constructive|Destructive|Link |-|-|-|-| |ARM64|64|256|https://godbolt.org/z/G7arf9nPP| |AVR|32|32|https://godbolt.org/z/Yq64f9Koj| |BPF|32|32|https://godbolt.org/z/zezK71zoe|

[clang] [C++17] Support __GCC_[CON|DE]STRUCTIVE_SIZE (PR #89446)

@@ -89,6 +89,19 @@ sections with improvements to Clang's support for those languages. C++ Language Changes +C++17 Feature Support +^ +- Clang now exposes ``__GCC_DESTRUCTIVE_SIZE`` and ``__GCC_CONSTRUCTIVE_SIZE`` + predefined macros

[clang] [BitInt] Expose a _BitInt literal suffix in C++ (PR #86586)

https://github.com/AaronBallman closed https://github.com/llvm/llvm-project/pull/86586 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang][Parser] Don't always destroy template annotations at the end of a declaration (PR #89494)

https://github.com/AaronBallman approved this pull request. LGTM! https://github.com/llvm/llvm-project/pull/89494 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang][Parser] Don't always destroy template annotations at the end of a declaration (PR #89494)

AaronBallman wrote: > > One question I have is whether it would make sense to modify > > DestroyTemplateIdAnnotationsRAIIObj to not call MaybeDestroyTemplateIds() > > in the first place > > I’d love to try if it were feasible, but please note that the annotation > (that is, C from the

[clang] [C++17] Support __GCC_[CON|DE]STRUCTIVE_SIZE (PR #89446)

@@ -89,6 +89,19 @@ sections with improvements to Clang's support for those languages. C++ Language Changes +C++17 Feature Support +^ +- Clang now exposes ``__GCC_DESTRUCTIVE_SIZE`` and ``__GCC_CONSTRUCTIVE_SIZE`` + predefined macros

[clang] [clang-tools-extra] [PAC][clang] Define `PointerAuthQualifier` and `PointerAuthenticationMode` (PR #84384)

AaronBallman wrote: > > > @AaronBallman See test results from compile-time-tracker here: > > > https://llvm-compile-time-tracker.com/compare.php?from=693a458287d019c5c6a66fe3019d099df2978cdb=dbb5e29d136a18060ba6759b328ad80fa9cea649. > > > It looks like that there is a statistically meaningful

[clang] Carving out -Wformat warning about scoped enums into a subwarning (PR #88595)

https://github.com/AaronBallman approved this pull request. LGTM! https://github.com/llvm/llvm-project/pull/88595 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang][Parser] Don't always destroy template annotations at the end of a declaration (PR #89494)

AaronBallman wrote: > My feeling is that it's not worth the complexity. Getting an accurate > benchmak would be difficult, it would only manifest in extremely templated > code I wonder if @AaronBallman has opinion. I think the complexity may be worth it -- FWIW, this originally came from

[clang] [Clang] Diagnose apply AST consume actions on LLVM IR (PR #88602)

https://github.com/AaronBallman approved this pull request. LGTM! > I still have some questions, should we give tips to the user that which > options cannot apply on LLVM IR files? I think the diagnostic you've got is reasonable -- these options are CC1 options which are not something we

[clang] [C++17] Support __GCC_[CON|DE]STRUCTIVE_SIZE (PR #89446)

AaronBallman wrote: > > > For SystemZ the correct value is 256. > > > > > > Thanks! Double-checking: for both constructive and destructive? > > Yes, for both. Every SystemZ model (supported by GCC/LLVM) has a L1 cache > line size of 256 bytes. Excellent, thank you! > > > In general I agree

[clang] [Clang][Sema] Remove unused function after #88731 (PR #89618)

https://github.com/AaronBallman approved this pull request. LGTM, thank you for catching that! https://github.com/llvm/llvm-project/pull/89618 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[clang] [C23] Select the correct promoted type for a bit-field (PR #89254)

https://github.com/AaronBallman closed https://github.com/llvm/llvm-project/pull/89254 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang] Fix __is_trivially_equaltiy_comparable documentation (PR #88528)

https://github.com/AaronBallman approved this pull request. LGTM! https://github.com/llvm/llvm-project/pull/88528 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] CTAD: implement the missing IsDeducible constraint for alias templates (PR #89358)

@@ -868,13 +868,7 @@ C++20 implementation status Class template argument deduction for alias templates https://wg21.link/p1814r0;>P1814R0 - - - Clang 19 (Partial) - The associated constraints (over.match.class.deduct#3.3) for

[clang] [clang] CTAD: implement the missing IsDeducible constraint for alias templates (PR #89358)

AaronBallman wrote: > > Regarding the __is_deducible type trait, GCC also provides one, but it was > > hidden from users and only used for internal CTAD implementation. I'm not > > sure if we should follow the same strategy in clang, ideas? > > I have mixed feeling. What do you think

[clang] [C++17] Support __GCC_[CON|DE]STRUCTIVE_SIZE (PR #89446)

AaronBallman wrote: > For SystemZ the correct value is 256. Thanks! Double-checking: for both constructive and destructive? > In general I agree it makes sense to look at the GCC implementation as a > source of reasonable values. Also, I think there probably should be no > generic default

[clang] [C++17] Support __GCC_[CON|DE]STRUCTIVE_SIZE (PR #89446)

AaronBallman wrote: > Sorry, I know nothing about it. But it looks to me it's to match with GCC, > why don't borrow the value from GCC as a beginning? Because the values depend on the target and the compiler options picked. I don't have that information myself, and given how many targets and

[clang] [C++17] Support __GCC_[CON|DE]STRUCTIVE_SIZE (PR #89446)

AaronBallman wrote: > @AaronBallman Did you read > https://discourse.llvm.org/t/rfc-c-17-hardware-constructive-destructive-interference-size/48674/42 > ? I want to make sure we do abide by it and it's unclear a consensus was > ever formed or called Yes, I looked at the thread and while there

[clang] [C++17] Support __GCC_[CON|DE]STRUCTIVE_SIZE (PR #89446)

AaronBallman wrote: During today's office hours, @philnik777 mentioned that support for these macros would be very beneficial to libc++ folks. This is intended as a starting point for the support in that it does not currently have any special logic for any particular target and it does not

[clang] [C23] Select the correct promoted type for a bit-field (PR #89254)

@@ -0,0 +1,38 @@ +// RUN: %clang_cc1 -fsyntax-only -verify -std=c23 %s + +// GH87641 noticed that integer promotion of a bit-field of bit-precise integer +// type was promoting to int rather than the type of the bit-field. +struct S { + unsigned _BitInt(7) x : 2; + unsigned

[clang] [Clang] Allow raw string literals in C as an extension (PR #88265)

@@ -130,6 +130,12 @@ struct LangStandard { /// hasDigraphs - Language supports digraphs. bool hasDigraphs() const { return Flags & Digraphs; } + /// hasRawStringLiterals - Language supports R"()" raw string literals. + bool hasRawStringLiterals() const { +// GCC

[clang] [C23] Select the correct promoted type for a bit-field (PR #89254)

AaronBallman wrote: > > @tbaederr -- this triggers an assertion with the new constexpr interpreter > > in `clang/test/AST/Interp/intap.cpp` but I'm not certain I understand why. > > Can you help me figure out how to fix that? > >

[clang] Stop double-diagnosing explicit convert operator in switch condition (PR #89142)

https://github.com/AaronBallman approved this pull request. The changes should come with a release note, but this LGTM otherwise https://github.com/llvm/llvm-project/pull/89142 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[clang] [Clang] Allow raw string literals in C as an extension (PR #88265)

@@ -130,6 +130,12 @@ struct LangStandard { /// hasDigraphs - Language supports digraphs. bool hasDigraphs() const { return Flags & Digraphs; } + /// hasRawStringLiterals - Language supports R"()" raw string literals. + bool hasRawStringLiterals() const { +// GCC

[clang] [Clang] Allow raw string literals in C as an extension (PR #88265)

@@ -43,6 +43,9 @@ code bases. C/C++ Language Potentially Breaking Changes --- +- Clang now supports raw string literals in ``-std=gnuXY`` mode as an extension in + C. This behaviour can also be overridden using

[clang] [Clang] Allow raw string literals in C as an extension (PR #88265)

https://github.com/AaronBallman edited https://github.com/llvm/llvm-project/pull/88265 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang] Allow raw string literals in C as an extension (PR #88265)

https://github.com/AaronBallman commented: Thank you for working on this! Broadly speaking, I think the idea makes a lot of sense. > GCC does not seem to support raw string literals in C++ before C++11, even > if e.g. -std=gnu++03 is passed. Should we follow this behaviour or should we >

[clang] [C23] Select the correct promoted type for a bit-field (PR #89254)

AaronBallman wrote: @tbaederr -- this triggers an assertion with the new constexpr interpreter in `clang/test/AST/Interp/intap.cpp` but I'm not certain I understand why. Can you help me figure out how to fix that? https://github.com/llvm/llvm-project/pull/89254

[clang] [BitInt] Expose a _BitInt literal suffix in C++ (PR #86586)

@@ -80,7 +80,10 @@ class NumericLiteralParser { bool isFloat128 : 1; // 1.0q bool isFract : 1; // 1.0hr/r/lr/uhr/ur/ulr bool isAccum : 1; // 1.0hk/k/lk/uhk/uk/ulk - bool isBitInt : 1;// 1wb, 1uwb (C23) + // clang-format off + bool isBitInt

[clang] [BitInt] Expose a _BitInt literal suffix in C++ (PR #86586)

https://github.com/AaronBallman approved this pull request. Aside from a nit with clang-format commenting, LGTM! @Sirraide are you happy with the state of things (you've got a "request changes" for your review). @erichkeane are you happy as well?

[clang] [BitInt] Expose a _BitInt literal suffix in C++ (PR #86586)

https://github.com/AaronBallman edited https://github.com/llvm/llvm-project/pull/86586 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [PAC][clang] Define `PointerAuthQualifier` and `PointerAuthenticationMode` (PR #84384)

AaronBallman wrote: > @AaronBallman See test results from compile-time-tracker here: > https://llvm-compile-time-tracker.com/compare.php?from=693a458287d019c5c6a66fe3019d099df2978cdb=dbb5e29d136a18060ba6759b328ad80fa9cea649. > > It looks like that there is a statistically meaningful

[clang] [clang-tools-extra] [PAC][clang] Define `PointerAuthQualifier` and `PointerAuthenticationMode` (PR #84384)

AaronBallman wrote: > I've fixed the build failure > https://buildkite.com/llvm-project/github-pull-requests/builds/55986 in > clang-tidy by only taking fast qualifiers from the `uint64_t` opaque value > and casting the value to `unsigned` - see >

[clang] Carving out -Wformat warning about scoped enums into a subwarning (PR #88595)

https://github.com/AaronBallman commented: Please be sure to add a release note in clang/docs/ReleaseNotes.rst. The code changes themselves LGTM, but there are some issues with the tests. https://github.com/llvm/llvm-project/pull/88595 ___

[clang] Carving out -Wformat warning about scoped enums into a subwarning (PR #88595)

@@ -1,5 +1,5 @@ -// RUN: %clang_cc1 -fsyntax-only -verify -Wformat %s -// RUN: %clang_cc1 -fsyntax-only -fdiagnostics-parseable-fixits -Wformat %s 2>&1 | FileCheck %s +// RUN: %clang_cc1 -fsyntax-only -verify -Wformat-pedantic %s AaronBallman wrote: We're

<    5   6   7   8   9   10   11   12   13   14   >