[clang] [clang] implement current direction of CWG2765 for string literal comparisons in constant evaluation (PR #109208)

@@ -1306,3 +1306,18 @@ constexpr int field(int a) { static_assert(field(3), ""); // expected-error {{constant expression}} \ // expected-note {{in call to 'field(3)'}} } + +namespace literal_comparison { + +constexpr bool different_in_loop(bool b =

[clang] [clang] implement current direction of CWG2765 for string literal comparisons in constant evaluation (PR #109208)

https://github.com/zygoloid updated https://github.com/llvm/llvm-project/pull/109208 >From 81193568c17a89f6cf42f43a82fb1fbf0f90184d Mon Sep 17 00:00:00 2001 From: Richard Smith Date: Wed, 18 Sep 2024 21:59:56 + Subject: [PATCH 1/4] Implement current CWG direction for string literal compari

[clang] [clang] implement current direction of CWG2765 for string literal comparisons in constant evaluation (PR #109208)

https://github.com/zygoloid updated https://github.com/llvm/llvm-project/pull/109208 >From 81193568c17a89f6cf42f43a82fb1fbf0f90184d Mon Sep 17 00:00:00 2001 From: Richard Smith Date: Wed, 18 Sep 2024 21:59:56 + Subject: [PATCH 1/5] Implement current CWG direction for string literal compari

[clang] [clang] implement current direction of CWG2765 for string literal comparisons in constant evaluation (PR #109208)

@@ -2142,11 +2150,81 @@ static const ValueDecl *GetLValueBaseDecl(const LValue &LVal) { return LVal.Base.dyn_cast(); } -static bool IsLiteralLValue(const LValue &Value) { - if (Value.getLValueCallIndex()) +// Information about an LValueBase that is some kind of string. +st

[clang] [clang] implement current direction of CWG2765 for string literal comparisons in constant evaluation (PR #109208)

@@ -2142,11 +2150,81 @@ static const ValueDecl *GetLValueBaseDecl(const LValue &LVal) { return LVal.Base.dyn_cast(); } -static bool IsLiteralLValue(const LValue &Value) { - if (Value.getLValueCallIndex()) +// Information about an LValueBase that is some kind of string. +st

[clang] [clang] implement current direction of CWG2765 for string literal comparisons in constant evaluation (PR #109208)

https://github.com/zygoloid updated https://github.com/llvm/llvm-project/pull/109208 >From 81193568c17a89f6cf42f43a82fb1fbf0f90184d Mon Sep 17 00:00:00 2001 From: Richard Smith Date: Wed, 18 Sep 2024 21:59:56 + Subject: [PATCH 1/7] Implement current CWG direction for string literal compari

[clang] [clang] implement current direction of CWG2765 for string literal comparisons in constant evaluation (PR #109208)

https://github.com/zygoloid updated https://github.com/llvm/llvm-project/pull/109208 >From 81193568c17a89f6cf42f43a82fb1fbf0f90184d Mon Sep 17 00:00:00 2001 From: Richard Smith Date: Wed, 18 Sep 2024 21:59:56 + Subject: [PATCH 1/8] Implement current CWG direction for string literal compari

[clang] [clang] implement current direction of CWG2765 for string literal comparisons in constant evaluation (PR #109208)

https://github.com/zygoloid updated https://github.com/llvm/llvm-project/pull/109208 >From 81193568c17a89f6cf42f43a82fb1fbf0f90184d Mon Sep 17 00:00:00 2001 From: Richard Smith Date: Wed, 18 Sep 2024 21:59:56 + Subject: [PATCH 1/9] Implement current CWG direction for string literal compari

[clang] [clang] implement current direction of CWG2765 for string literal comparisons in constant evaluation (PR #109208)

https://github.com/zygoloid updated https://github.com/llvm/llvm-project/pull/109208 >From 81193568c17a89f6cf42f43a82fb1fbf0f90184d Mon Sep 17 00:00:00 2001 From: Richard Smith Date: Wed, 18 Sep 2024 21:59:56 + Subject: [PATCH 01/10] Implement current CWG direction for string literal compa

[clang] [clang] implement current direction of CWG2765 for string literal comparisons in constant evaluation (PR #109208)

@@ -2142,11 +2150,81 @@ static const ValueDecl *GetLValueBaseDecl(const LValue &LVal) { return LVal.Base.dyn_cast(); } -static bool IsLiteralLValue(const LValue &Value) { - if (Value.getLValueCallIndex()) +// Information about an LValueBase that is some kind of string. +st

[clang] [clang] implement current direction of CWG2765 for string literal comparisons in constant evaluation (PR #109208)

@@ -2142,11 +2150,81 @@ static const ValueDecl *GetLValueBaseDecl(const LValue &LVal) { return LVal.Base.dyn_cast(); } -static bool IsLiteralLValue(const LValue &Value) { - if (Value.getLValueCallIndex()) +// Information about an LValueBase that is some kind of string. +st

[clang] [clang] implement current direction of CWG2765 for string literal comparisons in constant evaluation (PR #109208)

https://github.com/zygoloid commented: We need to figure out what we want to do about modules, but I think I've addressed the rest of the comments. https://github.com/llvm/llvm-project/pull/109208 ___ cfe-commits mailing list cfe-commits@lists.llvm.or

[clang] [clang] implement current direction of CWG2765 for string literal comparisons in constant evaluation (PR #109208)

@@ -96,6 +96,8 @@ def note_constexpr_pointer_constant_comparison : Note< "at runtime">; def note_constexpr_literal_comparison : Note< "comparison of addresses of literals has unspecified value">; +def note_constexpr_opaque_call_comparison : Note< + "comparison against opaq

[clang] [clang] implement current direction of CWG2765 for string literal comparisons in constant evaluation (PR #109208)

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

[clang] [clang] implement current direction of CWG2765 for string literal comparisons in constant evaluation (PR #109208)

@@ -324,6 +324,13 @@ class ASTContext : public RefCountedBase { /// This is lazily created. This is intentionally not serialized. mutable llvm::StringMap StringLiteralCache; + /// The next string literal "version" to allocate during constant evaluation. + /// This is us

[clang] [clang] implement current direction of CWG2765 for string literal comparisons in constant evaluation (PR #109208)

@@ -2061,15 +2063,21 @@ static bool EvaluateIgnoredValue(EvalInfo &Info, const Expr *E) { return true; } -/// Should this call expression be treated as a no-op? -static bool IsNoOpCall(const CallExpr *E) { +/// Should this call expression be treated as forming an opaque con

[clang] Make [[clang::lifetimebound]] work for expressions coming from default arguments (PR #112047)

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

[clang] Make [[clang::lifetimebound]] work for expressions coming from default arguments (PR #112047)

https://github.com/zygoloid approved this pull request. Thanks, looks good to me too. https://github.com/llvm/llvm-project/pull/112047 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Don't redundantly specify the default template argument to `BumpPtrAllocatorImpl` (PR #114857)

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

[clang] Enable AST mutation in the constant evaluator (PR #115168)

zygoloid wrote: If we do end up needing this (and it's looking increasingly likely that we will), I think the general approach of having a set of callbacks that gets passed into the constant evaluator is the right approach. I think the older approach in this PR (a callback object that is expli

[clang] [C23] Fixed the value of BOOL_WIDTH (PR #117364)

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

[clang] Enable AST mutation in the constant evaluator (PR #115168)

zygoloid wrote: > 1. Asking users to pass additional parameter to every `Eval*()` function > makes a bad transition story for users that wish to upgrade to a version of > Clang that has changed the interface in this way. External callers of the `Eval*` functions in almost all cases should not

[clang] Enable AST mutation in the constant evaluator (PR #115168)

zygoloid wrote: > > the special "the language rules say this is manifestly constant evaluated" > > cases that should be able to perform AST mutations, that we need to be > > extremely careful to invoke at exactly the right times and in exactly the > > right cases and to invoke only once > > C

[clang] [clang][UBSan] Make sure that the implicit-conversion group is compatible with minimal runtime (PR #114865)

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

[clang] [clang][UBSan] Make sure that the implicit-conversion group is compatible with minimal runtime (PR #114865)

https://github.com/zygoloid commented: Please can you also add a test that we allow combining `-fsanitize=implicit-conversion` and `-fsanitize-minimal-runtime` so that this doesn't regress in a similar way in future? (It'd be great if the test covered all the sanitizer groups that are currentl

[clang] [clang][UBSan] Make sure that the implicit-conversion group is compatible with minimal runtime (PR #114865)

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

[clang] [clang][ExprConst] Reject field access with nullptr base (PR #113885)

zygoloid wrote: As mentioned in the comment thread, I'd prefer to see this addressed by reversing the order in which we call `addDecl` versus add an offset. While it's a corner case, I think this change would cause us to start rejecting things like [this example](https://godbolt.org/z/5Pae6Ghd

[clang] [clang][ExprConst] Reject field access with nullptr base (PR #113885)

https://github.com/zygoloid approved this pull request. LG, thank you! https://github.com/llvm/llvm-project/pull/113885 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Document that the lifetime of the caller-side `trivial_abi` parameter ends before the call. (PR #116100)

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

[clang] Enable AST mutation in the constant evaluator (PR #115168)

zygoloid wrote: > Hey Richard - We added idempotency to `define_aggregate` in response to > concern from Clang maintainers that it could interact poorly with > `clang-repl`. The argument was that idempotency would provide a better > experience for a user that wanted to re-evaluate an expressio

[clang] Enable AST mutation in the constant evaluator (PR #115168)

zygoloid wrote: > @zygoloid would it be correct to say that you want the Standard to leave > idempotency of functions with side effects up to implementations, and, > consequently, you want the model of how side effects are integrated into > constant evaluation to work for both idempotent and n

[clang] Enable AST mutation in the constant evaluator (PR #115168)

zygoloid wrote: > I initially was of the same opinion as you, but I think we would have to > modify most call sites It seems to me that we'd need to modify those call sites that want to perform an evaluation of a "plainly constant-evaluated expression". Aren't those exactly the call sites we

[clang] [clang-tools-extra] [llvm] [Clang] Add __builtin_type_pack_dedup template to deduplicate types in template arguments (PR #106730)

@@ -3158,6 +3161,33 @@ checkBuiltinTemplateIdType(Sema &SemaRef, BuiltinTemplateDecl *BTD, int64_t N = Index.getExtValue(); return Ts.getPackAsArray()[N].getAsType(); } + case BTK__type_pack_dedup: { +assert(Converted.size() == 2 && "__builtin_type_pack_dedup sh

[clang] Enable AST mutation in the constant evaluator (PR #115168)

zygoloid wrote: > I think there's a contradiction between what `define_aggregate` needs and > that hypothetical `write_char_to_file` needs from the same language construct > (which is currently called _plainly constant-evaluated expression_). If we > say that we're not going to guarantee idemp

[clang] [clang][ExprConst] Add diagnostics for invalid binary arithmetic (PR #118475)

Timm =?utf-8?q?Bäder?= Message-ID: In-Reply-To: @@ -14548,8 +14548,21 @@ bool IntExprEvaluator::VisitBinaryOperator(const BinaryOperator *E) { return Error(E); const Expr *LHSExpr = LHSValue.Base.dyn_cast(); const Expr *RHSExpr = RHSValue.Base.dyn_cast()

[clang] [Clang] Add "extend lifetime" flags and release note (PR #110000)

https://github.com/zygoloid commented: I think this flag name is going to be extremely confusing. "lifetime" is a notion defined formally by the C++ language standard, and "lifetime extension" is again a process defined in C++ with a specific meaning. Those meanings have nothing to do with wha

[clang] [Clang] Add "extend lifetime" flags and release note (PR #110000)

zygoloid wrote: Looks like the tests in #110102 are named `extend-liveness-*.cpp`. Perhaps `-fextend-liveness` would be a good name for this flag? https://github.com/llvm/llvm-project/pull/11 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[clang] [Clang] Add "extend lifetime" flags and release note (PR #110000)

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

[clang] [C++20] Deleting destructors can be noexcept (PR #118687)

@@ -654,6 +654,9 @@ Bug Fixes in This Version - Fixed a crash when GNU statement expression contains invalid statement (#GH113468). - Fixed a failed assertion when using ``__attribute__((noderef))`` on an ``_Atomic``-qualified type (#GH116124). +- No longer return ``false``

[clang] [C++20] Deleting destructors can be noexcept (PR #118687)

@@ -1205,11 +1205,12 @@ CanThrowResult Sema::canThrow(const Stmt *S) { if (DTy.isNull() || DTy->isDependentType()) { CT = CT_Dependent; } else { - CT = canCalleeThrow(*this, DE, DE->getOperatorDelete()); + const FunctionDecl *OperatorDelete = DE->getOper

[clang] [C++20] Deleting destructors can be noexcept (PR #118687)

@@ -1206,15 +1206,16 @@ CanThrowResult Sema::canThrow(const Stmt *S) { CT = CT_Dependent; } else { const FunctionDecl *OperatorDelete = DE->getOperatorDelete(); - CT = canCalleeThrow(*this, DE, OperatorDelete); - if (const RecordType *RT = DTy->getAs()

[clang] [clang][ExprConst] Add diagnostics for invalid binary arithmetic (PR #118475)

https://github.com/zygoloid commented: Thanks! I think this is an improvement as-is, but while we're looking at this it'd be useful to make the existing diagnostics (and the new ones that are mirroring them) a little bit more precise about what the problem is. https://github.com/llvm/llvm-proj

[clang] [clang][ExprConst] Add diagnostics for invalid binary arithmetic (PR #118475)

@@ -91,11 +91,15 @@ def note_constexpr_pointer_subtraction_zero_size : Note< "subtraction of pointers to type %0 of zero size">; def note_constexpr_pointer_comparison_unspecified : Note< "comparison between '%0' and '%1' has unspecified value">; +def note_constexpr_pointer_

[clang] [clang][ExprConst] Add diagnostics for invalid binary arithmetic (PR #118475)

@@ -14548,8 +14548,21 @@ bool IntExprEvaluator::VisitBinaryOperator(const BinaryOperator *E) { return Error(E); const Expr *LHSExpr = LHSValue.Base.dyn_cast(); const Expr *RHSExpr = RHSValue.Base.dyn_cast(); - if (!LHSExpr || !RHSExpr) -return

[clang] [clang][ExprConst] Add diagnostics for invalid binary arithmetic (PR #118475)

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

[clang] [clang][ExprConst] Add diagnostics for invalid binary arithmetic (PR #118475)

@@ -14548,8 +14548,21 @@ bool IntExprEvaluator::VisitBinaryOperator(const BinaryOperator *E) { return Error(E); const Expr *LHSExpr = LHSValue.Base.dyn_cast(); const Expr *RHSExpr = RHSValue.Base.dyn_cast(); - if (!LHSExpr || !RHSExpr) -return

[clang] Resolving issue #119101 (PR #119143)

zygoloid wrote: Did you mean a different issue than #119101? It's not clear to me what connection this PR has to that issue. It's not clear to me that there's an issue to be solved here. Under `-pedantic-errors`, clang [already produces an error](https://godbolt.org/z/h6oKarex9) on examples l

[clang] [C++20] Destroying delete can cause a type to be noexcept when deleting (PR #118687)

zygoloid wrote: Hm, the issue raised in #118800 is relevant here too, isn't it? If the destructor is virtual, we want to look at its exception specification, not the one on the destroying operator delete, because `delete p` actually invokes the virtual deleting destructor, not the statically s

[clang] [C++20] Destroying delete and deleted destructors (PR #118800)

zygoloid wrote: As I just noted in #118687, I think we also need similar treatment for `noexcept(delete p)`. https://github.com/llvm/llvm-project/pull/118800 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailma

[clang] [C++20] Destroying delete and deleted destructors (PR #118800)

@@ -3768,6 +3768,28 @@ Sema::ActOnCXXDelete(SourceLocation StartLoc, bool UseGlobal, DeclarationName DeleteName = Context.DeclarationNames.getCXXOperatorName( ArrayForm ? OO_Array_Delete : OO_Delete); +// C++20 [expr.delete]p6: If

[clang] [C++20] Destroying delete and deleted destructors (PR #118800)

@@ -3768,6 +3768,28 @@ Sema::ActOnCXXDelete(SourceLocation StartLoc, bool UseGlobal, DeclarationName DeleteName = Context.DeclarationNames.getCXXOperatorName( ArrayForm ? OO_Array_Delete : OO_Delete); +// C++20 [expr.delete]p6: If

[clang] [C++20] Destroying delete and deleted destructors (PR #118800)

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

[clang] [C++20] Destroying delete and deleted destructors (PR #118800)

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

[clang] [C++20] Destroying delete and deleted destructors (PR #118800)

@@ -1200,21 +1200,35 @@ CanThrowResult Sema::canThrow(const Stmt *S) { case Expr::CXXDeleteExprClass: { auto *DE = cast(S); -CanThrowResult CT; +CanThrowResult CT = CT_Cannot; QualType DTy = DE->getDestroyedType(); if (DTy.isNull() || DTy->isDependentTy

[clang] [C++20] Destroying delete and deleted destructors (PR #118800)

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

[clang] [clang] print correct context for diagnostics suppressed by deduction (PR #125453)

zygoloid wrote: Thank you for tackling this longstanding issue! How much does saving this extra state add to the runtime and memory usage on a template-heavy compilation? If the cost is concerning, one other option we could consider here would be performing pending local instantiations eagerly

[clang] [C23] Fixed the value of BOOL_WIDTH (PR #117364)

@@ -1103,7 +1103,15 @@ static void InitializePredefinedMacros(const TargetInfo &TI, assert(TI.getCharWidth() == 8 && "Only support 8-bit char so far"); Builder.defineMacro("__CHAR_BIT__", Twine(TI.getCharWidth())); - Builder.defineMacro("__BOOL_WIDTH__", Twine(TI.getBool

[clang] [C23] Fixed the value of BOOL_WIDTH (PR #117364)

@@ -1103,7 +1103,15 @@ static void InitializePredefinedMacros(const TargetInfo &TI, assert(TI.getCharWidth() == 8 && "Only support 8-bit char so far"); Builder.defineMacro("__CHAR_BIT__", Twine(TI.getCharWidth())); - Builder.defineMacro("__BOOL_WIDTH__", Twine(TI.getBool

[clang] [clang][ExprConst] Add diagnostics for invalid binary arithmetic (PR #118475)

@@ -91,11 +91,15 @@ def note_constexpr_pointer_subtraction_zero_size : Note< "subtraction of pointers to type %0 of zero size">; def note_constexpr_pointer_comparison_unspecified : Note< "comparison between '%0' and '%1' has unspecified value">; +def note_constexpr_pointer_

[clang] Switch builtin strings to use string tables (PR #118734)

https://github.com/zygoloid approved this pull request. LGTM too. I do wonder if we can make tablegen generate the data directly in the desired format here (perhaps with some additional `.td` files to define exactly which files we want to include in which targets and to define the placeholder

[clang] [Clang] Add "extend lifetime" flags and release note (PR #110000)

https://github.com/zygoloid commented: New flag name LGTM. https://github.com/llvm/llvm-project/pull/11 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang][Sema] Reject declaring an alias template with the same name as its template parameter. (PR #123533)

@@ -65,7 +65,8 @@ namespace InFunctions { template struct S3 { // expected-note {{template parameter is declared here}} template using T = int; // expected-error {{declaration of 'T' shadows template parameter}} }; - template using Z = Z; + template // expected-note

[clang] [Clang][Sema] Reject declaring an alias template with the same name as its template parameter. (PR #123533)

https://github.com/zygoloid commented: This change looks good to me. https://github.com/llvm/llvm-project/pull/123533 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang][Sema] Reject declaring an alias template with the same name as its template parameter. (PR #123533)

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

[clang] [Clang][Sema] Reject declaring an alias template with the same name as its template parameter. (PR #123533)

@@ -13464,6 +13464,14 @@ Decl *Sema::ActOnAliasDeclaration(Scope *S, AccessSpecifier AS, } TemplateParameterList *TemplateParams = TemplateParamLists[0]; +// Check shadowing of a template parameter name +for (NamedDecl *TP : TemplateParams->asArray()) { +

[clang] [Clang][P1061] Add stuctured binding packs (PR #121417)

@@ -951,28 +959,124 @@ Sema::ActOnDecompositionDeclarator(Scope *S, Declarator &D, return New; } +// CheckBindingsCount zygoloid wrote: We [don't start function comments with the function name](https://llvm.org/docs/CodingStandards.html#commenting:~:text=

[clang] [Clang][P1061] Add stuctured binding packs (PR #121417)

@@ -951,28 +959,124 @@ Sema::ActOnDecompositionDeclarator(Scope *S, Declarator &D, return New; } +// CheckBindingsCount +// - Checks the arity of the structured bindings +// - Creates the resolved pack expr if there is +//one +static bool CheckBindingsCount(Sema &S, D

[clang] [Clang][P1061] Add stuctured binding packs (PR #121417)

@@ -4213,8 +4226,35 @@ class DecompositionDecl final static DecompositionDecl *CreateDeserialized(ASTContext &C, GlobalDeclID ID, unsigned NumBindings); - ArrayRef bindings() const { -return llvm::ArrayRef(getTrailingObject

[clang] [Clang][P1061] Add stuctured binding packs (PR #121417)

@@ -951,28 +959,124 @@ Sema::ActOnDecompositionDeclarator(Scope *S, Declarator &D, return New; } +// CheckBindingsCount +// - Checks the arity of the structured bindings +// - Creates the resolved pack expr if there is +//one +static bool CheckBindingsCount(Sema &S, D

[clang] [Clang][P1061] Add stuctured binding packs (PR #121417)

@@ -5321,6 +5321,59 @@ class BuiltinBitCastExpr final } }; +// Represents an unexpanded pack where the list of expressions are +// known. These are used when structured bindings introduce a pack. +class ResolvedUnexpandedPackExpr final zygoloid wrote: This

[clang] [Clang][P1061] Add stuctured binding packs (PR #121417)

@@ -1099,6 +1099,13 @@ def err_lambda_capture_misplaced_ellipsis : Error< "the name of the capture">; def err_lambda_capture_multiple_ellipses : Error< "multiple ellipses in pack capture">; +def err_binding_multiple_ellipses : Error< + "multiple ellipses in structured bind

[clang] [AArch64] Match GCC behaviour for zero-size structs (PR #124760)

zygoloid wrote: Also, is it worth adding `-fclang-abi-compat=` support to control this change? https://github.com/llvm/llvm-project/pull/124760 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-

[clang] [llvm] [Clang] restrict use of attribute names reserved by the C++ standard (PR #106036)

zygoloid wrote: Oh, I see, you're suggesting we remove the `getStdNamespace` check from this PR. Yeah, I think that's reasonable. But I'd somewhat question whether this PR and warning really has anything to do with the attribute names being "reserved" at that point -- we're not checking wheth

[clang] [C++20] Destroying delete and deleted destructors (PR #118800)

@@ -2855,6 +2855,11 @@ class CXXDestructorDecl : public CXXMethodDecl { return getCanonicalDecl()->OperatorDeleteThisArg; } + /// Will this destructor ever be called when considering which deallocation + /// function is associated with the destructor? Can optionally be

[clang] [C++20] Destroying delete and deleted destructors (PR #118800)

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

[clang] [C++20] Destroying delete and deleted destructors (PR #118800)

https://github.com/zygoloid approved this pull request. LG other than the function name. https://github.com/llvm/llvm-project/pull/118800 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commit

[clang] [Clang] Add "extend lifetime" flags and release note (PR #110000)

@@ -412,6 +412,20 @@ New Compiler Flags only for thread-local variables, and none (which corresponds to the existing ``-fno-c++-static-destructors`` flag) skips all static destructors registration. +- The ``-fextend-variable-liveness`` flag has been added to allow for imp

[clang] [Clang] Add "extend lifetime" flags and release note (PR #110000)

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

[clang] [Clang] Force expressions with UO_Not to not be non-negative (PR #126846)

zygoloid wrote: > Would it be possible to provide better fine grained control over the > `-Wsign-compare` so the clang could still flag the the cases like the one in > the summary but ignore the cases where implicit conversion has no side > effects or UB? The warning being produced is a `-Wim

[clang] [Clang] Force expressions with UO_Not to not be non-negative (PR #126846)

zygoloid wrote: > > But still I feel generate a warning for this case went too far. > > Yeah, that's probably right. Maybe for `-` on a signed operand, we should > just return the original range with the `NonNegative` flag cleared out, and > shouldn't add the extra bit for the `-128 -> 128` ed

[clang] [Sema] Diagnose by-value copy constructors in template instantiations (PR #130866)

zygoloid wrote: This error is [produced for the following code](https://github.com/carbon-language/carbon-lang/pull/5170): ```c++ template class SetView { SetView(SetView, KeyContextT> other_view) requires(!std::same_as>); }; ``` ... which is never an eligible copy constructor. Is that in

[clang] [clang-tools-extra] Suppress pedantic diagnostic for a file not ending in EOL (PR #131794)

@@ -627,8 +627,6 @@ buildPreamble(PathRef FileName, CompilerInvocation CI, return DiagnosticsEngine::Ignored; switch (Info.getID()) { case diag::warn_no_newline_eof: -case diag::warn_cxx98_compat_no_newline_eof: -case diag::ext_no_newline_eof: // If

[clang] [clang-tools-extra] Suppress pedantic diagnostic for a file not ending in EOL (PR #131794)

https://github.com/zygoloid commented: LG https://github.com/llvm/llvm-project/pull/131794 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] Suppress pedantic diagnostic for a file not ending in EOL (PR #131794)

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

[clang] [C++20][Modules] Prevent premature call to PassInterestingDeclsToConsumer() within FinishedDeserializing(). (PR #129982)

https://github.com/zygoloid commented: Thanks, the explanation and code change makes sense to me. Should this bugfix have a release note? https://github.com/llvm/llvm-project/pull/129982 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://

[clang] [C++20][Modules] Prevent premature call to PassInterestingDeclsToConsumer() within FinishedDeserializing(). (PR #129982)

zygoloid wrote: Thank you! I can imagine figuring out what was wrong here was not easy! https://github.com/llvm/llvm-project/pull/129982 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [C++20][Modules] Prevent premature call to PassInterestingDeclsToConsumer() within FinishedDeserializing(). (PR #129982)

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

[clang] [clang-tools-extra] Suppress pedantic diagnostic for a file not ending in EOL (PR #131794)

@@ -127,8 +127,10 @@ C2y Feature Support that ``_Generic`` selection associations may now have ``void`` type, but it also removes UB with code like ``(void)(void)1;``. - Implemented `WG14 N3411 `_ - which allows

[clang-tools-extra] [clang-tidy] Switch misc-confusable-identifiers check to a faster algorithm. (PR #130369)

zygoloid wrote: Ping. https://github.com/llvm/llvm-project/pull/130369 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang] Force expressions with UO_Not to not be non-negative (PR #126846)

zygoloid wrote: > But still I feel generate a warning for this case went too far. Yeah, that's probably right. Maybe for `-` on a signed operand, we should just return the original range with the `NonNegative` flag cleared out, and shouldn't add the extra bit for the `-128 -> 128` edge case. T

[clang] Reject invalid integer constants in unevaluated preprocessor operands (PR #134884)

https://github.com/zygoloid approved this pull request. LGTM. I suppose if people complain, we can make the non-live value case a warning rather than an error, but given no other implementation does, I think it makes sense not to do that speculatively. https://github.com/llvm/llvm-project/pul

[clang] No longer add enumeration constants to the wrong scope (PR #134998)

zygoloid wrote: I thought CWG's preferred direction on this was to reject entirely? https://github.com/llvm/llvm-project/pull/134998 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] No longer add enumeration constants to the wrong scope (PR #134998)

zygoloid wrote: This came up on the core reflector again just yesterday; would be worth asking there. https://github.com/llvm/llvm-project/pull/134998 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listi

[clang-tools-extra] [clang-tidy] Switch misc-confusable-identifiers check to a faster algorithm. (PR #130369)

zygoloid wrote: Ping. https://github.com/llvm/llvm-project/pull/130369 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang][RFC] Bypass TAD during overload resolution if a perfect match exists (PR #133426)

@@ -8455,11 +8524,17 @@ void Sema::AddNonMemberOperatorCandidates( if (FunTmpl) { AddTemplateOverloadCandidate(FunTmpl, F.getPair(), ExplicitTemplateArgs, FunctionArgs, CandidateSet); - if (CandidateSet.getRewriteInfo().shouldAd

[clang] [Clang][RFC] Bypass TAD during overload resolution if a perfect match exists (PR #133426)

@@ -10230,9 +10307,15 @@ Sema::AddArgumentDependentLookupCandidates(DeclarationName Name, /*AllowExplicit=*/true, ADLCallKind::UsesADL); if (CandidateSet.getRewriteInfo().shouldAddReversed( *this, Args, FTD->getTemplatedDecl())) { + +// As

[clang] [Clang][RFC] Bypass TAD during overload resolution if a perfect match exists (PR #133426)

https://github.com/zygoloid commented: I think we should do this. Even if WG21 decides that they only want to allow this and not require it, it seems like a good change that we stand a decent chance of reaching implementation consensus on. https://github.com/llvm/llvm-project/pull/133426 _

[clang] Disable -fdollars-in-identifiers by default (PR #135407)

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

[clang] Disable -fdollars-in-identifiers by default (PR #135407)

@@ -119,7 +119,7 @@ LANGOPT(WChar , 1, 0, "wchar_t keyword") LANGOPT(Char8 , 1, 0, "char8_t keyword") LANGOPT(IEEE128 , 1, 0, "__ieee128 keyword") LANGOPT(DeclSpecKeyword , 1, 0, "__declspec keyword") -BENIGN_LANGOPT(DollarIdents , 1, 1, "'

[clang] Disable -fdollars-in-identifiers by default (PR #135407)

@@ -1,5 +1,5 @@ // REQUIRES: x86-registered-target -// RUN: %clang_cc1 %s -triple i386-apple-darwin10 -fasm-blocks -emit-llvm -o - | FileCheck %s +// RUN: %clang_cc1 %s -triple i386-apple-darwin10 -fdollars-in-identifiers -fasm-blocks -emit-llvm -o - | FileCheck %s

<    37   38   39   40   41   42   43   >