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

@@ -8,79 +8,60 @@ Standard C++ Modules Introduction -The term ``modules`` has a lot of meanings. For the users of Clang, modules may -refer to ``Objective-C Modules``, ``Clang C++ Modules`` (or ``Clang Header Modules``, -etc.) or ``Standard C++ Modules``. The

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

@@ -8,79 +8,60 @@ Standard C++ Modules Introduction -The term ``modules`` has a lot of meanings. For the users of Clang, modules may -refer to ``Objective-C Modules``, ``Clang C++ Modules`` (or ``Clang Header Modules``, -etc.) or ``Standard C++ Modules``. The

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

@@ -530,43 +527,43 @@ Now the linkage name of ``NS::foo()`` will be ``_ZN2NS3fooEv``. Module Initializers ~~~ -All the importable module units are required to emit an initializer function. -The initializer function should contain calls to importing modules

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

@@ -444,53 +435,57 @@ For example, the following example is allowed: # Inconsistent debugging level. $ clang++ -std=c++20 -g Use.cpp -fprebuilt-module-path=. -Although the two examples have inconsistent optimization and debugging level, both of them are accepted.

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

@@ -1753,17 +1740,18 @@ Possible Questions How modules speed up compilation -A classic theory for the reason why modules speed up the compilation is: -if there are ``n`` headers and ``m`` source files and each header is included by each

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

@@ -633,36 +631,36 @@ example: // module M's interface, so is discarded int c = use_h(); // OK -In the above example, the function definition of ``N::g`` is elided from the Reduced -BMI of ``M.cppm``. Then the use of ``use_g`` in

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

@@ -530,43 +527,43 @@ Now the linkage name of ``NS::foo()`` will be ``_ZN2NS3fooEv``. Module Initializers ~~~ -All the importable module units are required to emit an initializer function. -The initializer function should contain calls to importing modules

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

@@ -8,79 +8,60 @@ Standard C++ Modules Introduction -The term ``modules`` has a lot of meanings. For the users of Clang, modules may -refer to ``Objective-C Modules``, ``Clang C++ Modules`` (or ``Clang Header Modules``, -etc.) or ``Standard C++ Modules``. The

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

@@ -216,51 +198,56 @@ We explain the options in the following sections. How to enable standard C++ modules ~~ -Currently, standard C++ modules are enabled automatically -if the language standard is ``-std=c++20`` or newer. +Standard C++ modules

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

@@ -8,79 +8,60 @@ Standard C++ Modules Introduction -The term ``modules`` has a lot of meanings. For the users of Clang, modules may -refer to ``Objective-C Modules``, ``Clang C++ Modules`` (or ``Clang Header Modules``, -etc.) or ``Standard C++ Modules``. The

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

@@ -8,79 +8,60 @@ Standard C++ Modules Introduction -The term ``modules`` has a lot of meanings. For the users of Clang, modules may -refer to ``Objective-C Modules``, ``Clang C++ Modules`` (or ``Clang Header Modules``, -etc.) or ``Standard C++ Modules``. The

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

@@ -216,51 +198,56 @@ We explain the options in the following sections. How to enable standard C++ modules ~~ -Currently, standard C++ modules are enabled automatically -if the language standard is ``-std=c++20`` or newer. +Standard C++ modules

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

@@ -95,22 +76,23 @@ In this document, we use the following umbrella terms: * A ``module interface unit`` refers to either a ``primary module interface unit`` erichkeane wrote: ^^ Line above but github wont let me: Don't use 'umbrella', its probably not a

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

@@ -8,79 +8,60 @@ Standard C++ Modules Introduction -The term ``modules`` has a lot of meanings. For the users of Clang, modules may -refer to ``Objective-C Modules``, ``Clang C++ Modules`` (or ``Clang Header Modules``, -etc.) or ``Standard C++ Modules``. The

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

@@ -8,79 +8,60 @@ Standard C++ Modules Introduction -The term ``modules`` has a lot of meanings. For the users of Clang, modules may -refer to ``Objective-C Modules``, ``Clang C++ Modules`` (or ``Clang Header Modules``, -etc.) or ``Standard C++ Modules``. The

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

@@ -8,79 +8,60 @@ Standard C++ Modules Introduction -The term ``modules`` has a lot of meanings. For the users of Clang, modules may -refer to ``Objective-C Modules``, ``Clang C++ Modules`` (or ``Clang Header Modules``, -etc.) or ``Standard C++ Modules``. The

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

@@ -8,79 +8,60 @@ Standard C++ Modules Introduction -The term ``modules`` has a lot of meanings. For the users of Clang, modules may -refer to ``Objective-C Modules``, ``Clang C++ Modules`` (or ``Clang Header Modules``, -etc.) or ``Standard C++ Modules``. The

[clang] [Clang] Fix incorrect handling of #pragma {GCC} unroll N in dependent context (PR #90240)

@@ -124,3 +124,40 @@ void test(int *List, int Length) { #pragma unroll /* expected-error {{expected statement}} */ } + +using size_t = unsigned long long; + +template erichkeane wrote: This test isn't particularly good, since it is validating that it

[clang] [Clang] Fix incorrect handling of #pragma {GCC} unroll N in dependent context (PR #90240)

@@ -109,16 +109,20 @@ static Attr *handleLoopHintAttr(Sema , Stmt *St, const ParsedAttr , SetHints(LoopHintAttr::Unroll, LoopHintAttr::Disable); } else if (PragmaName == "unroll") { // #pragma unroll N -if (ValueExpr && !ValueExpr->isValueDependent()) { -

[clang] [Clang] Fix incorrect handling of #pragma {GCC} unroll N in dependent context (PR #90240)

@@ -109,16 +109,20 @@ static Attr *handleLoopHintAttr(Sema , Stmt *St, const ParsedAttr , SetHints(LoopHintAttr::Unroll, LoopHintAttr::Disable); } else if (PragmaName == "unroll") { // #pragma unroll N -if (ValueExpr && !ValueExpr->isValueDependent()) { -

[clang] [Clang] Implement C++26 Attributes for Structured Bindings (P0609R3) (PR #89906)

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

[clang] [NFC] Factor out common parts of ArraySections into its own class (PR #89639)

@@ -74,12 +74,12 @@ void use() { for (int i = 0; i < 10; ++i) { // FIXME: Once we have a new array-section type to represent OpenACC as // well, change this error message. erichkeane wrote: Thanks, done in bb1a8bbb

[clang] [NFC] Factor out common parts of ArraySections into its own class (PR #89639)

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

[clang] [Clang] Implement P2809: Trivial infinite loops are not Undefined Behavior (PR #90066)

@@ -131,6 +131,8 @@ C++2c Feature Support - Implemented `P2573R2: = delete("should have a reason"); `_ +- Implemented `P2573R2: = delete("should have a reason"); `_ erichkeane wrote: What is going on

[clang] [Clang] Implement P2809: Trivial infinite loops are not Undefined Behavior (PR #90066)

@@ -908,6 +908,73 @@ void CodeGenFunction::EmitIfStmt(const IfStmt ) { incrementProfileCounter(); } +bool CodeGenFunction::checkIfLoopMustProgress(const Expr *ControllingExpression, + bool IsTrivialCXXLoop) { + if

[clang] [Clang] Implement P2809: Trivial infinite loops are not Undefined Behavior (PR #90066)

@@ -908,6 +908,73 @@ void CodeGenFunction::EmitIfStmt(const IfStmt ) { incrementProfileCounter(); } +bool CodeGenFunction::checkIfLoopMustProgress(const Expr *ControllingExpression, + bool IsTrivialCXXLoop) { + if

[clang] [Clang] Implement P2809: Trivial infinite loops are not Undefined Behavior (PR #90066)

@@ -908,6 +908,73 @@ void CodeGenFunction::EmitIfStmt(const IfStmt ) { incrementProfileCounter(); } +bool CodeGenFunction::checkIfLoopMustProgress(const Expr *ControllingExpression, + bool IsTrivialCXXLoop) { + if

[clang] [Clang] Implement C++26 Attributes for Structured Bindings (P0609R3) (PR #89906)

@@ -102,11 +102,21 @@ namespace PR33839 { for (auto [x] : a) { // expected-warning {{unused variable '[x]'}} } } - void use() { + void use() { f(); // expected-note {{instantiation of}} g(); g(); h(); // expected-note {{instantiation of}} }

[clang] [Clang] Implement C++26 Attributes for Structured Bindings (P0609R3) (PR #89906)

erichkeane wrote: > > Thank you working on this. I'm really like this feature! I've a question, > > do we have any further plans to support GNU extension attributes(e.g. > > **attribute**((aligned)))? Although it is not included in the paper. > > No, sorry! > > My goal here is to increase

[clang] [Clang] Implement C++26 P2748R5 "Disallow Binding a Returned Glvalue to a Temporary" (PR #89942)

@@ -9950,6 +9950,8 @@ def warn_ret_stack_addr_ref : Warning< def warn_ret_local_temp_addr_ref : Warning< "returning %select{address of|reference to}0 local temporary object">, InGroup; +def err_ret_local_temp_addr_ref : Error< + "returning %select{address of|reference

[clang] [Clang] Implement C++26 P2748R5 "Disallow Binding a Returned Glvalue to a Temporary" (PR #89942)

https://github.com/erichkeane approved this pull request. 1 Nit, else LGTM, the CWG issue change seems sensible, as does the rest. https://github.com/llvm/llvm-project/pull/89942 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[clang] [Clang] Implement C++26 P2748R5 "Disallow Binding a Returned Glvalue to a Temporary" (PR #89942)

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

[clang] [Clang][Sema] fix a bug on template partial specialization (PR #89862)

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

[clang] [NFC] Factor out common parts of ArraySections into its own class (PR #89639)

erichkeane wrote: I think I've got everything done you were concerned about. Let me know if you see anything else! https://github.com/llvm/llvm-project/pull/89639 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[clang] [Clang][Sema] fix a bug on template partial specialization (PR #89862)

@@ -7706,7 +7706,7 @@ ExprResult Sema::CheckTemplateArgument(NonTypeTemplateParmDecl *Param, // FIXME: The language rules don't say what happens in this case. // FIXME: We get an opaque dependent type out of decltype(auto) if the // expression is merely

[clang] [NFC] Factor out common parts of ArraySections into its own class (PR #89639)

@@ -11163,7 +11163,7 @@ def err_omp_declare_mapper_redefinition : Error< "redefinition of user-defined mapper for type %0 with name %1">; def err_omp_invalid_mapper: Error< "cannot find a valid user-defined mapper for type %0 with name %1">; -def err_omp_array_section_use

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

erichkeane 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

[clang] [NFC] Factor out common parts of ArraySections into its own class (PR #89639)

@@ -3413,8 +3413,8 @@ StringRef BuiltinType::getName(const PrintingPolicy ) const { return "reserve_id_t"; case IncompleteMatrixIdx: return ""; - case OMPArraySection: -return ""; + case ArraySection: +return ""; erichkeane wrote:

[clang] [NFC] Factor out common parts of ArraySections into its own class (PR #89639)

@@ -11762,20 +11770,25 @@ TreeTransform::TransformOMPArraySectionExpr(OMPArraySectionExpr *E) { } ExprResult Stride; - if (Expr *Str = E->getStride()) { -Stride = getDerived().TransformExpr(Str); -if (Stride.isInvalid()) - return ExprError(); + if

[clang] [NFC] Factor out common parts of ArraySections into its own class (PR #89639)

@@ -443,12 +443,17 @@ ExprDependence clang::computeDependence(ObjCIndirectCopyRestoreExpr *E) { return E->getSubExpr()->getDependence(); } -ExprDependence clang::computeDependence(OMPArraySectionExpr *E) { +ExprDependence clang::computeDependence(ArraySectionExpr *E) {

[clang] [NFC] Factor out common parts of ArraySections into its own class (PR #89639)

@@ -11163,7 +11163,7 @@ def err_omp_declare_mapper_redefinition : Error< "redefinition of user-defined mapper for type %0 with name %1">; def err_omp_invalid_mapper: Error< "cannot find a valid user-defined mapper for type %0 with name %1">; -def err_omp_array_section_use

[clang] [NFC] Factor out common parts of ArraySections into its own class (PR #89639)

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

[clang] [NFC] Factor out common parts of ArraySections into its own class (PR #89639)

https://github.com/erichkeane commented: I opted to leave the type of both array sections the same as it seems like it will save a bunch of work and complexity, at the expense of 1 'print', and potentially 1 diagnostic. Let me know if you think this is an important distinction!

[clang] [clang] deprecate frelaxed-template-template-args, make it on by default (PR #89807)

@@ -8343,58 +8343,52 @@ bool Sema::CheckTemplateTemplateArgument(TemplateTemplateParmDecl *Param, // C++1z [temp.arg.template]p3: (DR 150) // A template-argument matches a template template-parameter P when P // is at least as specialized as the template-argument A.

[clang] Reapply "[Clang][Sema] placement new initializes typedef array with correct size (#83124)" (PR #89036)

erichkeane wrote: > @mahtohappy can we please revert this in the meantime while you look for a > fix here. Feel free to land it again with the fix. He's likely outside of work hours, but feel free to submit a revert. https://github.com/llvm/llvm-project/pull/89036

[clang] [clang] deprecate frelaxed-template-template-args, make it on by default (PR #89807)

@@ -8343,58 +8343,52 @@ bool Sema::CheckTemplateTemplateArgument(TemplateTemplateParmDecl *Param, // C++1z [temp.arg.template]p3: (DR 150) // A template-argument matches a template template-parameter P when P // is at least as specialized as the template-argument A.

[clang] [clang] deprecate frelaxed-template-template-args, make it on by default (PR #89807)

@@ -8343,58 +8343,52 @@ bool Sema::CheckTemplateTemplateArgument(TemplateTemplateParmDecl *Param, // C++1z [temp.arg.template]p3: (DR 150) // A template-argument matches a template template-parameter P when P // is at least as specialized as the template-argument A.

[clang] [clang] deprecate frelaxed-template-template-args, make it on by default (PR #89807)

https://github.com/erichkeane commented: Also needs a release note, entry into breaking changes, and a post on mailing list or whatever for the 'breaking change' subscribers to pay attention to. https://github.com/llvm/llvm-project/pull/89807 ___

[clang] [clang] deprecate frelaxed-template-template-args, make it on by default (PR #89807)

@@ -8343,58 +8343,52 @@ bool Sema::CheckTemplateTemplateArgument(TemplateTemplateParmDecl *Param, // C++1z [temp.arg.template]p3: (DR 150) // A template-argument matches a template template-parameter P when P // is at least as specialized as the template-argument A.

[clang] [clang] deprecate frelaxed-template-template-args, make it on by default (PR #89807)

@@ -6561,7 +6561,7 @@ void Clang::ConstructJob(Compilation , const JobAction , if (const Arg *A = Args.getLastArg(options::OPT_fvisibility_global_new_delete_hidden)) { D.Diag(diag::warn_drv_deprecated_arg) -<< A->getAsString(Args) +<<

[clang] [clang] deprecate frelaxed-template-template-args, make it on by default (PR #89807)

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

[clang] [clang] deprecate frelaxed-template-template-args, make it on by default (PR #89807)

https://github.com/erichkeane commented: We probably need to attach this to ClangABI as well, this is an ABI breaking change. https://github.com/llvm/llvm-project/pull/89807 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[clang] [NFC] Factor out common parts of ArraySections into its own class (PR #89639)

erichkeane wrote: > > @alexey-bataev Not having this new 'base' type as a member of the > > `StmtNodes.td` results in one of the Clang tools failing (see the CI). AND, > > since it is a template, it can't do that. > > I can't make it a Mixin, because it needs to provide some of the Expr-type

[clang] [NFC] Factor out common parts of ArraySections into its own class (PR #89639)

erichkeane wrote: @alexey-bataev Not having this new 'base' type as a member of the `StmtNodes.td` results in one of the Clang tools failing (see the CI). AND, since it is a template, it can't do that. I can't make it a Mixin, because it needs to provide some of the Expr-type functions

[clang] Reapply "[Clang][Sema] placement new initializes typedef array with correct size (#83124)" (PR #89036)

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

[clang] Reapply "[Clang][Sema] placement new initializes typedef array with correct size (#83124)" (PR #89036)

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

[clang] [NFC] Factor out common parts of ArraySections into its own class (PR #89639)

erichkeane wrote: @njames93 : My test failure has to do with the "NodeIntrospection" stuff that you seemed to review ~3 years ago: https://reviews.llvm.org/D93164 At the moment, I cannot even figure out how to get it to build, but I suspect it is getting confused in some way by having a

[clang] Don't wrap immediate invocations in ConstantExprs within constexpr initializers (PR #89565)

https://github.com/erichkeane commented: I don't have a great idea on this one, but losing the diagnostics seems incorrect. I think the whole initializer should probably be treated in 1 shot as a constant expr (so move the ConstantExpr to the top (above the `ImplicitCastExpr` in your

[clang] Don't wrap immediate invocations in ConstantExprs within constexpr initializers (PR #89565)

@@ -9,8 +9,7 @@ using MaxBitInt = _BitInt(128); constexpr _BitInt(2) A = 0; constexpr _BitInt(2) B = A + 1; -constexpr _BitInt(2) C = B + 1; // expected-warning {{from 2 to -2}} \ -// ref-warning {{from 2 to -2}} +constexpr _BitInt(2) C = B +

[clang] Don't wrap immediate invocations in ConstantExprs within constexpr initializers (PR #89565)

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

[clang] Don't wrap immediate invocations in ConstantExprs within constexpr initializers (PR #89565)

@@ -244,8 +244,8 @@ namespace UndefinedBehavior { constexpr int n13 = n5 + n5; // expected-error {{constant expression}} expected-note {{value -4294967296 is outside the range of }} constexpr int n14 = n3 - n5; // expected-error {{constant expression}} expected-note

[clang] [NFC] Factor out common parts of ArraySections into its own class (PR #89639)

https://github.com/erichkeane updated https://github.com/llvm/llvm-project/pull/89639 >From b95304b22915217ad149c1b22a6517c585067acf Mon Sep 17 00:00:00 2001 From: erichkeane Date: Mon, 22 Apr 2024 10:35:13 -0700 Subject: [PATCH 1/3] [NFC] Factor out common parts of ArraySections into its own

[clang] [NFC] Factor out common parts of ArraySections into its own class (PR #89639)

@@ -6610,6 +6610,111 @@ class TypoExpr : public Expr { }; +// This is a sub-class for OpenMP and OpenACC array sections. OpenACC uses a +// very small subset of the functionality, so this class only exposes the things +// the two have in common. This type is not expected to

[clang] [NFC] Factor out common parts of ArraySections into its own class (PR #89639)

https://github.com/erichkeane updated https://github.com/llvm/llvm-project/pull/89639 >From b95304b22915217ad149c1b22a6517c585067acf Mon Sep 17 00:00:00 2001 From: erichkeane Date: Mon, 22 Apr 2024 10:35:13 -0700 Subject: [PATCH 1/2] [NFC] Factor out common parts of ArraySections into its own

[clang] [NFC] Factor out common parts of ArraySections into its own class (PR #89639)

erichkeane wrote: Note: this is one of my approaches. This ends up touching the OpenMP work 'the least' (in that this is the entirety of the OpenMP changes as best I can tell), at the expense of more work/a separate AST Node for OpenACC. The OTHER approach I have is to move/rename

[clang] [NFC] Factor out common parts of ArraySections into its own class (PR #89639)

https://github.com/erichkeane created https://github.com/llvm/llvm-project/pull/89639 OpenACC is going to need an array sections implementation that is a simpler version/more restrictive version of the OpenMP version. This patch extracts the things that should be common between the two into

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

erichkeane wrote: At least the windows failure seems completely unrelated, it is a 'flang' build failure, likely caused by you getting 'unlucky' and the build being broken at the time. You DO have a conflict to resolve, so perhaps doing that will get you back to green.

[clang] [OpenACC] Implement 'num_gangs' sema for compute constructs (PR #89460)

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

[clang] [OpenACC] Implement 'num_gangs' sema for compute constructs (PR #89460)

https://github.com/erichkeane updated https://github.com/llvm/llvm-project/pull/89460 >From aa7844c73b72172707ec81234c8e9d5370bbb772 Mon Sep 17 00:00:00 2001 From: erichkeane Date: Fri, 19 Apr 2024 10:20:40 -0700 Subject: [PATCH 1/2] [OpenACC] Implement 'num_gangs' sema for compute constructs

[clang] [clang] Distinguish unresolved templates in UnresolvedLookupExpr (PR #89019)

@@ -186,3 +186,74 @@ class E { #endif template using D = int; // expected-note {{declared here}} E ed; // expected-note {{instantiation of}} + +namespace non_functions { + +#if __cplusplus >= 201103L +namespace PR88832 { +template struct O { + static const T v = 0; +}; +

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

https://github.com/erichkeane approved this pull request. This seems reasonable to me. 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] Mark ill-formed partial specialization as invalid (PR #89536)

https://github.com/erichkeane approved this pull request. Release note, else LGTM. https://github.com/llvm/llvm-project/pull/89536 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [AST] Dump argument types for TypeTraitExpr. (PR #89370)

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

[clang] [OpenACC] Implement 'num_gangs' sema for compute constructs (PR #89460)

https://github.com/erichkeane created https://github.com/llvm/llvm-project/pull/89460 num_gangs takes an 'int-expr-list', for 'parallel', and an 'int-expr' for 'kernels'. This patch changes the parsing to always parse it as an 'int-expr-list', then correct the expression count during Sema.

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

https://github.com/erichkeane approved this pull request. 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] Reapply "[Clang][Sema] placement new initializes typedef array with correct size (#83124)" (PR #89036)

@@ -0,0 +1,23 @@ +// RUN: %clang --target=x86_64-pc-linux -S -fno-discard-value-names -emit-llvm -o - %s | FileCheck %s + +namespace std { erichkeane wrote: Tests STILL haven't changed from the original patch. Please add the regression to this test as well.

[clang] Reapply "[Clang][Sema] placement new initializes typedef array with correct size (#83124)" (PR #89036)

@@ -12864,6 +12864,19 @@ TreeTransform::TransformCXXNewExpr(CXXNewExpr *E) { ArraySize = NewArraySize.get(); } + // Per C++0x [expr.new]p5, the type being constructed may be a + // typedef of an array type. + QualType AllocType = AllocTypeInfo->getType(); + if

[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] [C23] Select the correct promoted type for a bit-field (PR #89254)

https://github.com/erichkeane approved this pull request. This change looks right to me! I don't know if there is value in a signed-test instead of unsigned, but a couple more tests might be nice anyway. https://github.com/llvm/llvm-project/pull/89254

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

https://github.com/erichkeane edited 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] CTAD: Fix require-clause is not transformed. (PR #89378)

https://github.com/erichkeane approved this pull request. https://github.com/llvm/llvm-project/pull/89378 ___ 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)

https://github.com/erichkeane edited https://github.com/llvm/llvm-project/pull/89358 ___ 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)

@@ -3207,6 +3241,59 @@ Sema::DeduceTemplateArguments(VarTemplatePartialSpecializationDecl *Partial, return ::DeduceTemplateArguments(*this, Partial, TemplateArgs, Info); } +TemplateDeductionResult +Sema::DeduceTemplateArgumentsFromType(TemplateDecl *TD, QualType FromType,

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

@@ -6100,6 +6100,17 @@ static bool EvaluateBinaryTypeTrait(Sema , TypeTrait BTT, const TypeSourceI tok::kw___is_pointer_interconvertible_base_of); return Self.IsPointerInterconvertibleBaseOf(Lhs, Rhs); + } + case BTT_IsDeducible: { +if

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

https://github.com/erichkeane commented: Needs a release note, and I think we actually DO have to do those diagnostics here. https://github.com/llvm/llvm-project/pull/89358 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[clang] [AST] Dump argument types for TypeTraitExpr. (PR #89370)

https://github.com/erichkeane commented: It seems to me that exposing these as children is the better option here, right? That way it would better model a CallExpr or template type-trait, and would work in our StmtProfiler et-al. https://github.com/llvm/llvm-project/pull/89370

[clang] Reapply "[Clang][Sema] placement new initializes typedef array with correct size (#83124)" (PR #89036)

@@ -12864,6 +12864,19 @@ TreeTransform::TransformCXXNewExpr(CXXNewExpr *E) { ArraySize = NewArraySize.get(); } + // Per C++0x [expr.new]p5, the type being constructed may be a + // typedef of an array type. + QualType AllocType = AllocTypeInfo->getType(); + if

[clang] Reapply "[Clang][Sema] placement new initializes typedef array with correct size (#83124)" (PR #89036)

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

[clang] Reapply "[Clang][Sema] placement new initializes typedef array with correct size (#83124)" (PR #89036)

https://github.com/erichkeane commented: Where is the repro from the original author? What did they share, and what ended up being the solution/test here for it? https://github.com/llvm/llvm-project/pull/89036 ___ cfe-commits mailing list

[clang] [Clang][Sema] Diagnose explicit specializations with object parameters that do not match their primary template (PR #89300)

https://github.com/erichkeane commented: Code changes seem fine so far. https://github.com/llvm/llvm-project/pull/89300 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [OpenACC] Implement 'num_workers' clause for compute constructs (PR #89151)

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

[clang] [OpenACC] Implement 'num_workers' clause for compute constructs (PR #89151)

https://github.com/erichkeane updated https://github.com/llvm/llvm-project/pull/89151 >From d3894971090921b92c71ba5a18151cb2033c8cfa Mon Sep 17 00:00:00 2001 From: erichkeane Date: Tue, 16 Apr 2024 09:43:55 -0700 Subject: [PATCH 1/7] [OpenACC] Implement 'num_workers' clause for compute

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

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

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

https://github.com/erichkeane updated https://github.com/llvm/llvm-project/pull/89142 >From 43f1915f919d82f055e0c7147d3c46013d56feef Mon Sep 17 00:00:00 2001 From: erichkeane Date: Wed, 17 Apr 2024 11:46:36 -0700 Subject: [PATCH 1/2] Stop double-diagnosing explicit convert operator in switch

[clang] [Clang] Do not try to diagnose parameter packs in invalid pack expressions (PR #89257)

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

[clang] [OpenACC] Implement 'num_workers' clause for compute constructs (PR #89151)

@@ -156,6 +156,64 @@ class OpenACCSelfClause : public OpenACCClauseWithCondition { Expr *ConditionExpr, SourceLocation EndLoc); }; +/// Represents one of a handful of classes that have integer expressions. +/// Semantically, many only

[clang] [OpenACC] Implement 'num_workers' clause for compute constructs (PR #89151)

https://github.com/erichkeane updated https://github.com/llvm/llvm-project/pull/89151 >From d3894971090921b92c71ba5a18151cb2033c8cfa Mon Sep 17 00:00:00 2001 From: erichkeane Date: Tue, 16 Apr 2024 09:43:55 -0700 Subject: [PATCH 1/6] [OpenACC] Implement 'num_workers' clause for compute

[clang] [clang] Distinguish unresolved templates in UnresolvedLookupExpr (PR #89019)

@@ -186,3 +186,74 @@ class E { #endif template using D = int; // expected-note {{declared here}} E ed; // expected-note {{instantiation of}} + +namespace non_functions { + +#if __cplusplus >= 201103L +namespace PR88832 { +template struct O { + static const T v = 0; +}; +

[clang] [clang] Distinguish unresolved templates in UnresolvedLookupExpr (PR #89019)

@@ -186,3 +186,74 @@ class E { #endif template using D = int; // expected-note {{declared here}} E ed; // expected-note {{instantiation of}} + +namespace non_functions { + +#if __cplusplus >= 201103L +namespace PR88832 { +template struct O { + static const T v = 0; +}; +

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

erichkeane wrote: > > I've only ever seen that used in regards to the `RecoveryExpr`, so I think > > I am? > > It’s used in a few other places from what I can tell (e.g. see > `InitListExpr::markError()`); I think the result is the same either way (i.e. > `containsErrors()` ends up returning

<    1   2   3   4   5   6   7   8   9   10   >