[clang] [libcxx] Reapply "[Clang] Implement resolution for CWG1835 (#92957, #98547)" (PR #100425)

2024-08-01 Thread Krystian Stasiowski via cfe-commits
@@ -1779,6 +1779,42 @@ void Parser::checkPotentialAngleBracket(ExprResult ) { Priority); } +bool Parser::isMissingTemplateKeywordBeforeScope(bool AnnotateInvalid) { + assert(Tok.is(tok::coloncolon)); + Sema::DisableTypoCorrectionRAII DTC(Actions); +

[clang] [libcxx] Reapply "[Clang] Implement resolution for CWG1835 (#92957, #98547)" (PR #100425)

2024-07-31 Thread Krystian Stasiowski via cfe-commits
https://github.com/sdkrystian edited https://github.com/llvm/llvm-project/pull/100425 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [libcxx] Reapply "[Clang] Implement resolution for CWG1835 (#92957, #98547)" (PR #100425)

2024-07-31 Thread Krystian Stasiowski via cfe-commits
@@ -1779,6 +1779,42 @@ void Parser::checkPotentialAngleBracket(ExprResult ) { Priority); } +bool Parser::isMissingTemplateKeywordBeforeScope(bool AnnotateInvalid) { + assert(Tok.is(tok::coloncolon)); + Sema::DisableTypoCorrectionRAII DTC(Actions); +

[clang] [libcxx] Reapply "[Clang] Implement resolution for CWG1835 (#92957, #98547)" (PR #100425)

2024-07-30 Thread Krystian Stasiowski via cfe-commits
https://github.com/sdkrystian edited https://github.com/llvm/llvm-project/pull/100425 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [libcxx] Reapply "[Clang] Implement resolution for CWG1835 (#92957, #98547)" (PR #100425)

2024-07-30 Thread Krystian Stasiowski via cfe-commits
@@ -1779,6 +1779,42 @@ void Parser::checkPotentialAngleBracket(ExprResult ) { Priority); } +bool Parser::isMissingTemplateKeywordBeforeScope(bool AnnotateInvalid) { + assert(Tok.is(tok::coloncolon)); + Sema::DisableTypoCorrectionRAII DTC(Actions); +

[clang] [libcxx] Reapply "[Clang] Implement resolution for CWG1835 (#92957, #98547)" (PR #100425)

2024-07-30 Thread Krystian Stasiowski via cfe-commits
sdkrystian wrote: With these changes, we can now issue warnings for the missing `template` keyword in the _vast_ majority of cases: ```cpp template struct A { int x; }; template struct B { int x; }; template struct C { int x; }; template struct D { int x; }; template constexpr inline int V

[clang] [libcxx] Reapply "[Clang] Implement resolution for CWG1835 (#92957, #98547)" (PR #100425)

2024-07-30 Thread Krystian Stasiowski via cfe-commits
sdkrystian wrote: With these changes, we can now issue warnings for the missing `template` keyword in the _vast_ majority of cases: ```cpp template struct A { int x; }; template struct B { int x; }; template struct C { int x; }; template struct D { int x; }; template constexpr inline int V

[clang] [libcxx] Reapply "[Clang] Implement resolution for CWG1835 (#92957, #98547)" (PR #100425)

2024-07-30 Thread Krystian Stasiowski via cfe-commits
sdkrystian wrote: Also added support for names prefixed with the `template` keyword. https://github.com/llvm/llvm-project/pull/100425 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [libcxx] Reapply "[Clang] Implement resolution for CWG1835 (#92957, #98547)" (PR #100425)

2024-07-30 Thread Krystian Stasiowski via cfe-commits
https://github.com/sdkrystian edited https://github.com/llvm/llvm-project/pull/100425 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [libcxx] Reapply "[Clang] Implement resolution for CWG1835 (#92957, #98547)" (PR #100425)

2024-07-30 Thread Krystian Stasiowski via cfe-commits
sdkrystian wrote: I've further improved `isTemplateArgumentList` so we only consider `<` as the start of a potential template-argument-list if it follows an _identifier_ or the name in an _operator-function-id_/_literal-operator-id_ when trying to find the closing `>`. Also, explicit casts (a

[clang] [Clang][Parse] Fix ambiguity with nested-name-specifiers that may declarative (PR #96364)

2024-07-29 Thread Krystian Stasiowski via cfe-commits
https://github.com/sdkrystian closed https://github.com/llvm/llvm-project/pull/96364 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang][Parse] Fix ambiguity with nested-name-specifiers that may declarative (PR #96364)

2024-07-29 Thread Krystian Stasiowski via cfe-commits
sdkrystian wrote: I think this is ready to merge. I have [a branch](https://github.com/sdkrystian/llvm-project/tree/perf/backtrack-raii) which fully implements annotated/unannotated preprocessor backtrack using RAII objects, but I think this is beyond the scope of this PR.

[clang] [Clang][Parse] Fix ambiguity with nested-name-specifiers that may declarative (PR #96364)

2024-07-29 Thread Krystian Stasiowski via cfe-commits
https://github.com/sdkrystian updated https://github.com/llvm/llvm-project/pull/96364 >From 496e0cf24b07622bd9354297c20091c2057a55c6 Mon Sep 17 00:00:00 2001 From: Krystian Stasiowski Date: Wed, 12 Jun 2024 14:14:26 -0400 Subject: [PATCH 1/8] [Clang][Parse] Fix ambiguity with

[clang] [Clang][Parse] Fix ambiguity with nested-name-specifiers that may declarative (PR #96364)

2024-07-29 Thread Krystian Stasiowski via cfe-commits
https://github.com/sdkrystian updated https://github.com/llvm/llvm-project/pull/96364 >From 691b0d3b23aa89af08ff6b1f4e09ff62c4b36ef6 Mon Sep 17 00:00:00 2001 From: Krystian Stasiowski Date: Wed, 12 Jun 2024 14:14:26 -0400 Subject: [PATCH 1/8] [Clang][Parse] Fix ambiguity with

[clang] [Clang][Parse] Fix ambiguity with nested-name-specifiers that may declarative (PR #96364)

2024-07-29 Thread Krystian Stasiowski via cfe-commits
https://github.com/sdkrystian updated https://github.com/llvm/llvm-project/pull/96364 >From 037fb12412e9b3787e91d0a8ca826e098eab4e85 Mon Sep 17 00:00:00 2001 From: Krystian Stasiowski Date: Wed, 12 Jun 2024 14:14:26 -0400 Subject: [PATCH 1/8] [Clang][Parse] Fix ambiguity with

[clang] [Clang][Parse] Fix ambiguity with nested-name-specifiers that may declarative (PR #96364)

2024-07-29 Thread Krystian Stasiowski via cfe-commits
https://github.com/sdkrystian updated https://github.com/llvm/llvm-project/pull/96364 >From 037fb12412e9b3787e91d0a8ca826e098eab4e85 Mon Sep 17 00:00:00 2001 From: Krystian Stasiowski Date: Wed, 12 Jun 2024 14:14:26 -0400 Subject: [PATCH 1/7] [Clang][Parse] Fix ambiguity with

[clang] [libcxx] Reapply "[Clang] Implement resolution for CWG1835 (#92957, #98547)" (PR #100425)

2024-07-29 Thread Krystian Stasiowski via cfe-commits
@@ -767,6 +757,7 @@ bool Sema::BuildCXXNestedNameSpecifier(Scope *S, NestedNameSpecInfo , else Diag(IdInfo.IdentifierLoc, diag::err_undeclared_var_use) << IdInfo.Identifier; +#endif sdkrystian wrote: Yeah, these changes shouldn't really be part

[clang] [Clang][Sema] Make UnresolvedLookupExprs in class scope explicit specializations instantiation dependent (PR #100392)

2024-07-29 Thread Krystian Stasiowski via cfe-commits
https://github.com/sdkrystian updated https://github.com/llvm/llvm-project/pull/100392 >From c4f8a620a2a4692c9fa27b41f7e86c8cb042e533 Mon Sep 17 00:00:00 2001 From: Krystian Stasiowski Date: Wed, 24 Jul 2024 10:15:47 -0400 Subject: [PATCH] [Clang][Sema] Make UnresolvedLookupExprs in class

[clang] [libcxx] Reapply "[Clang] Implement resolution for CWG1835 (#92957, #98547)" (PR #100425)

2024-07-26 Thread Krystian Stasiowski via cfe-commits
sdkrystian wrote: > I am still concerned about the double error on the `t.A<1 < 4>::x` example. The ideal outcome would be to turn the second error into a note. How feasible to fix you think that is? That's trivial to fix, just need to add a note variant of the "missing template" diagnostic.

[clang] [libcxx] Reapply "[Clang] Implement resolution for CWG1835 (#92957, #98547)" (PR #100425)

2024-07-26 Thread Krystian Stasiowski via cfe-commits
sdkrystian wrote: @AaronBallman @cor3ntin @mizvekov So, I've made improvements to our implementation of `isTemplateArgumentList` that allow us to issue a warning instead of an error for most of the cases where applying the DR breaks existing code: ```cpp template struct A { int x; };

[clang] [Clang][Sema] Improve support for explicit specializations of constrained member functions & member function templates (PR #88963)

2024-07-25 Thread Krystian Stasiowski via cfe-commits
@@ -10339,24 +10339,53 @@ Sema::CheckMemberSpecialization(NamedDecl *Member, LookupResult ) { if (Previous.empty()) { // Nowhere to look anyway. } else if (FunctionDecl *Function = dyn_cast(Member)) { +SmallVector Candidates; +bool Ambiguous = false; for

[clang] [libcxx] Reapply "[Clang] Implement resolution for CWG1835 (#92957, #98547)" (PR #100425)

2024-07-24 Thread Krystian Stasiowski via cfe-commits
sdkrystian wrote: @KyunLFA Could you check if ares compiles with the patch applied using C++23 please? https://github.com/llvm/llvm-project/pull/100425 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[clang] [libcxx] Reapply "[Clang] Implement resolution for CWG1835 (#92957, #98547)" (PR #100425)

2024-07-24 Thread Krystian Stasiowski via cfe-commits
@@ -628,10 +628,12 @@ namespace cwg141 { // cwg141: 3.1 // expected-error@-1 {{use 'template' keyword to treat 'f' as a dependent template name}} } void h() { - (void)t.S::n; // ok + (void)t.S::n; sdkrystian wrote: @Endilll `t` is

[clang] [libcxx] Reapply "[Clang] Implement resolution for CWG1835 (#92957, #98547)" (PR #100425)

2024-07-24 Thread Krystian Stasiowski via cfe-commits
sdkrystian wrote: I'm considering whether to add a compatibility warning to ease the transition to the new behavior, e.g. ```cpp template struct A { int x; }; template struct B : A { void f() { this->A::f(); // warning `template` is required after '->' in C++23 and later } }; ```

[clang] [Clang][Sema] Make UnresolvedLookupExprs in class scope explicit specializations instantiation dependent (PR #100392)

2024-07-24 Thread Krystian Stasiowski via cfe-commits
sdkrystian wrote: > For tests, I think we can just dump & validate the AST for the > specialization, WDYT? Sounds reasonable, I'll do that. https://github.com/llvm/llvm-project/pull/100392 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[clang] [Clang][AST] Don't use canonical type when checking dependence in Type::isOverloadable (PR #98563)

2024-07-24 Thread Krystian Stasiowski via cfe-commits
https://github.com/sdkrystian closed https://github.com/llvm/llvm-project/pull/98563 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang][AST] Don't use canonical type when checking dependence in Type::isOverloadable (PR #98563)

2024-07-23 Thread Krystian Stasiowski via cfe-commits
https://github.com/sdkrystian updated https://github.com/llvm/llvm-project/pull/98563 >From fde01e26873828b9ab2aa1eb2ae1e1b6106b66c6 Mon Sep 17 00:00:00 2001 From: Krystian Stasiowski Date: Thu, 11 Jul 2024 18:28:50 -0400 Subject: [PATCH 1/3] [Clang][AST] Don't use canonical type when checking

[clang] [Clang][Parse] Fix ambiguity with nested-name-specifiers that may declarative (PR #96364)

2024-07-23 Thread Krystian Stasiowski via cfe-commits
https://github.com/sdkrystian updated https://github.com/llvm/llvm-project/pull/96364 >From 0d0a1e242db6a117ffb37ab4ce3d72e6adf26a2e Mon Sep 17 00:00:00 2001 From: Krystian Stasiowski Date: Wed, 12 Jun 2024 14:14:26 -0400 Subject: [PATCH 1/6] [Clang][Parse] Fix ambiguity with

[clang] [Clang][Parse] Fix ambiguity with nested-name-specifiers that may declarative (PR #96364)

2024-07-23 Thread Krystian Stasiowski via cfe-commits
https://github.com/sdkrystian updated https://github.com/llvm/llvm-project/pull/96364 >From 0d0a1e242db6a117ffb37ab4ce3d72e6adf26a2e Mon Sep 17 00:00:00 2001 From: Krystian Stasiowski Date: Wed, 12 Jun 2024 14:14:26 -0400 Subject: [PATCH 1/6] [Clang][Parse] Fix ambiguity with

[clang] [libcxx] [llvm] Reapply "[Clang] Implement resolution for CWG1835 (#92957)" (PR #98547)

2024-07-23 Thread Krystian Stasiowski via cfe-commits
sdkrystian wrote: @KyunLFA Could you send the commit hash of the clang build which you're using? I'm unable to reproduce. https://github.com/llvm/llvm-project/pull/98547 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[clang] [Clang][AST] Don't use canonical type when checking dependence in Type::isOverloadable (PR #98563)

2024-07-23 Thread Krystian Stasiowski via cfe-commits
https://github.com/sdkrystian updated https://github.com/llvm/llvm-project/pull/98563 >From 5cefddec13ca2bafb58a6f714fd2bef435166c8d Mon Sep 17 00:00:00 2001 From: Krystian Stasiowski Date: Thu, 11 Jul 2024 18:28:50 -0400 Subject: [PATCH 1/2] [Clang][AST] Don't use canonical type when checking

[clang] [Clang][AST] Don't use canonical type when checking dependence in Type::isOverloadable (PR #98563)

2024-07-22 Thread Krystian Stasiowski via cfe-commits
https://github.com/sdkrystian updated https://github.com/llvm/llvm-project/pull/98563 >From 5cefddec13ca2bafb58a6f714fd2bef435166c8d Mon Sep 17 00:00:00 2001 From: Krystian Stasiowski Date: Thu, 11 Jul 2024 18:28:50 -0400 Subject: [PATCH 1/2] [Clang][AST] Don't use canonical type when checking

[clang] [libcxx] [llvm] Reapply "[Clang] Implement resolution for CWG1835 (#92957)" (PR #98547)

2024-07-22 Thread Krystian Stasiowski via cfe-commits
sdkrystian wrote: [Ping](https://github.com/llvm/llvm-project/pull/98547#issuecomment-2240040530) @cor3ntin @AaronBallman. https://github.com/llvm/llvm-project/pull/98547 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[clang] [Clang][AST] Don't use canonical type when checking dependence in Type::isOverloadable (PR #98563)

2024-07-22 Thread Krystian Stasiowski via cfe-commits
https://github.com/sdkrystian updated https://github.com/llvm/llvm-project/pull/98563 >From 5cefddec13ca2bafb58a6f714fd2bef435166c8d Mon Sep 17 00:00:00 2001 From: Krystian Stasiowski Date: Thu, 11 Jul 2024 18:28:50 -0400 Subject: [PATCH 1/2] [Clang][AST] Don't use canonical type when checking

[clang] [libcxx] [llvm] Reapply "[Clang] Implement resolution for CWG1835 (#92957)" (PR #98547)

2024-07-22 Thread Krystian Stasiowski via cfe-commits
sdkrystian wrote: @mizvekov Consider a slightly altered version of the motivating example [in the DR](https://cplusplus.github.io/CWG/issues/1835.html): ```cpp template void end(); template bool Foo(T it0, T it1) { return it0->end < it1->end || it0->end > it1->end; } ``` `< it1->end ||

[clang] [libcxx] [llvm] Reapply "[Clang] Implement resolution for CWG1835 (#92957)" (PR #98547)

2024-07-22 Thread Krystian Stasiowski via cfe-commits
sdkrystian wrote: > > We already do that :) the problem is when what follows `A` _doesn't_ > > unambiguously look like a template argument list: > > Sure, but before CWG1835, we would perform the lookup anyway and treat the > `<0>` as a template argument list, even if it isn't unambiguously a

[clang] [libcxx] [llvm] Reapply "[Clang] Implement resolution for CWG1835 (#92957)" (PR #98547)

2024-07-22 Thread Krystian Stasiowski via cfe-commits
sdkrystian wrote: > Independent of the other issues, it looks like this also re-introduces #98878 @nico #98878 still occurs without this patch applied: ```cpp struct A { void f(); }; template int g(T t) { using U = A; // clang 18.1: 'warning: unused type alias 'U'' t.U::f(); } ```

[clang] [libcxx] [llvm] Reapply "[Clang] Implement resolution for CWG1835 (#92957)" (PR #98547)

2024-07-22 Thread Krystian Stasiowski via cfe-commits
sdkrystian wrote: > > I'm also seeing a hard "missing 'template' keyword prior to dependent > > template name" error when building the 510.parest_r benchmark from SPEC CPU > > 2017 > > Hitting this same error compiling the ares emulator on 19. Could either of you provide an example @KyunLFA

[clang] [libcxx] [llvm] Reapply "[Clang] Implement resolution for CWG1835 (#92957)" (PR #98547)

2024-07-19 Thread Krystian Stasiowski via cfe-commits
sdkrystian wrote: > > @mizvekov Without unannotated tentative parsing (to be _properly_ > > introduced by #96364), issuing a warning is infeasible. Either way, by the > > time we detect the error we could be who knows how deep into the second > > operand of a `>` operator. > > So when we are

[clang] [libcxx] [llvm] Reapply "[Clang] Implement resolution for CWG1835 (#92957)" (PR #98547)

2024-07-19 Thread Krystian Stasiowski via cfe-commits
sdkrystian wrote: > Another option would be to apply the resolution to all modes, but recover and > issue a warning instead of an error. How feasible would that be? @mizvekov Without unannotated tentative parsing (to be _properly_ introduced by #96364), issuing a warning is infeasible. Either

[clang] [libcxx] [llvm] Reapply "[Clang] Implement resolution for CWG1835 (#92957)" (PR #98547)

2024-07-19 Thread Krystian Stasiowski via cfe-commits
sdkrystian wrote: I have a [new branch](https://github.com/sdkrystian/llvm-project/tree/reapply-cwg-1835-again) ready where: - We only apply the resolution to CWG1835 in C++23 and later, and - We issue a diagnostic when its application results in a missing template keyword that breaks

[clang] [Clang][Parse] Fix ambiguity with nested-name-specifiers that may declarative (PR #96364)

2024-07-17 Thread Krystian Stasiowski via cfe-commits
https://github.com/sdkrystian updated https://github.com/llvm/llvm-project/pull/96364 >From 0d0a1e242db6a117ffb37ab4ce3d72e6adf26a2e Mon Sep 17 00:00:00 2001 From: Krystian Stasiowski Date: Wed, 12 Jun 2024 14:14:26 -0400 Subject: [PATCH 1/4] [Clang][Parse] Fix ambiguity with

[clang] [libcxx] [llvm] Reapply "[Clang] Implement resolution for CWG1835 (#92957)" (PR #98547)

2024-07-16 Thread Krystian Stasiowski via cfe-commits
sdkrystian wrote: @cor3ntin Well, if the alternative is not implementing the resolution at all I'll look into the feasibility of identifying missing `template` keywords in the non-type template parameter case. If I can get that working, I think it's pretty safe to reland this patch. Also, I

[clang] [clang-tools-extra] [Clang][AST] Move NamespaceDecl bits to DeclContext (PR #98567)

2024-07-15 Thread Krystian Stasiowski via cfe-commits
https://github.com/sdkrystian closed https://github.com/llvm/llvm-project/pull/98567 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [Clang][AST] Move NamespaceDecl bits to DeclContext (PR #98567)

2024-07-15 Thread Krystian Stasiowski via cfe-commits
sdkrystian wrote: > Is there any follow up work for this? @mizvekov Yes, but it's not directly related. I'm going to submit a patch in the future which stores the `SourceLocation` of the `inline` keyword for inline namespace, and perhaps another patch that extends `NestedNameSpecifier` such

[clang] [libcxx] [llvm] Reapply "[Clang] Implement resolution for CWG1835 (#92957)" (PR #98547)

2024-07-15 Thread Krystian Stasiowski via cfe-commits
https://github.com/sdkrystian edited https://github.com/llvm/llvm-project/pull/98547 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [libcxx] [llvm] Reapply "[Clang] Implement resolution for CWG1835 (#92957)" (PR #98547)

2024-07-15 Thread Krystian Stasiowski via cfe-commits
sdkrystian wrote: > I think the next reland needs to cover the non-type template case, so that we > have a way to suppress the warning for all cases (this gives developer time > to do the cleanup transition). @hokein The problem with the non-type template case is that we would have to check

[clang] [libcxx] [llvm] Reapply "[Clang] Implement resolution for CWG1835 (#92957)" (PR #98547)

2024-07-15 Thread Krystian Stasiowski via cfe-commits
sdkrystian wrote: > @opensdd You might want to know that CWG1835 is causing some disruption in > the wild > > I wonder if we should consider deploying that change _NOT_ as a DR such that > it would only affect C++23+ conformance, that might alleviate some of the > pain points. *@opensdh

[clang] [libcxx] [llvm] Reapply "[Clang] Implement resolution for CWG1835 (#92957)" (PR #98547)

2024-07-12 Thread Krystian Stasiowski via cfe-commits
sdkrystian wrote: @pranavk see #98613 https://github.com/llvm/llvm-project/pull/98547 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [Clang][AST] Move NamespaceDecl bits to DeclContext (PR #98567)

2024-07-12 Thread Krystian Stasiowski via cfe-commits
sdkrystian wrote: @Endilll Should I go ahead with this change anyways? https://github.com/llvm/llvm-project/pull/98567 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Add option to opt out of the missing_dependent_template_keyword diagnostic (PR #98613)

2024-07-12 Thread Krystian Stasiowski via cfe-commits
https://github.com/sdkrystian edited https://github.com/llvm/llvm-project/pull/98613 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Add option to opt out of the missing_dependent_template_keyword diagnostic (PR #98613)

2024-07-12 Thread Krystian Stasiowski via cfe-commits
https://github.com/sdkrystian approved this pull request. Reasonable, LGTM. https://github.com/llvm/llvm-project/pull/98613 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [Clang][AST] Move NamespaceDecl bits to DeclContext (PR #98567)

2024-07-12 Thread Krystian Stasiowski via cfe-commits
https://github.com/sdkrystian updated https://github.com/llvm/llvm-project/pull/98567 >From 63a9c69cc5c4d6f8048918addfb01de6dc212524 Mon Sep 17 00:00:00 2001 From: Krystian Stasiowski Date: Thu, 20 Jun 2024 11:44:53 -0400 Subject: [PATCH 1/3] [Clang][AST] Move NamespaceDecl bits to DeclContext

[clang] [clang-tools-extra] [Clang][AST] Move NamespaceDecl bits to DeclContext (PR #98567)

2024-07-12 Thread Krystian Stasiowski via cfe-commits
https://github.com/sdkrystian updated https://github.com/llvm/llvm-project/pull/98567 >From 63a9c69cc5c4d6f8048918addfb01de6dc212524 Mon Sep 17 00:00:00 2001 From: Krystian Stasiowski Date: Thu, 20 Jun 2024 11:44:53 -0400 Subject: [PATCH 1/2] [Clang][AST] Move NamespaceDecl bits to DeclContext

[clang] [libcxx] [llvm] Reapply "[Clang] Implement resolution for CWG1835 (#92957)" (PR #98547)

2024-07-12 Thread Krystian Stasiowski via cfe-commits
sdkrystian wrote: @glandium Yes, clang considers `std::move(*this)` to be dependent so `template` is required there. https://github.com/llvm/llvm-project/pull/98547 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[clang] [Clang][Parse] Fix ambiguity with nested-name-specifiers that may declarative (PR #96364)

2024-07-11 Thread Krystian Stasiowski via cfe-commits
https://github.com/sdkrystian updated https://github.com/llvm/llvm-project/pull/96364 >From ade60c6468cf3aa0b862734d403dffa2733afe3c Mon Sep 17 00:00:00 2001 From: Krystian Stasiowski Date: Wed, 12 Jun 2024 14:14:26 -0400 Subject: [PATCH 1/3] [Clang][Parse] Fix ambiguity with

[clang] [Clang][AST] Move NamespaceDecl bits to DeclContext (PR #98567)

2024-07-11 Thread Krystian Stasiowski via cfe-commits
https://github.com/sdkrystian created https://github.com/llvm/llvm-project/pull/98567 Currently, `NamespaceDecl` has a member `AnonOrFirstNamespaceAndFlags` which stores a few pieces of data: - a bit indicating whether the namespace was declared `inline`, and - a bit indicating whether the

[clang] [Clang][Parse] Fix ambiguity with nested-name-specifiers that may declarative (PR #96364)

2024-07-11 Thread Krystian Stasiowski via cfe-commits
https://github.com/sdkrystian updated https://github.com/llvm/llvm-project/pull/96364 >From ade60c6468cf3aa0b862734d403dffa2733afe3c Mon Sep 17 00:00:00 2001 From: Krystian Stasiowski Date: Wed, 12 Jun 2024 14:14:26 -0400 Subject: [PATCH 1/2] [Clang][Parse] Fix ambiguity with

[clang] [Clang][Parse] Fix ambiguity with nested-name-specifiers that may declarative (PR #96364)

2024-07-11 Thread Krystian Stasiowski via cfe-commits
https://github.com/sdkrystian updated https://github.com/llvm/llvm-project/pull/96364 >From 29f2e6e418d61de15453dbfca77ede0126b6d384 Mon Sep 17 00:00:00 2001 From: Krystian Stasiowski Date: Wed, 12 Jun 2024 14:14:26 -0400 Subject: [PATCH 1/2] [Clang][Parse] Fix ambiguity with

[clang] [libcxx] [llvm] Reapply "[Clang] Implement resolution for CWG1835 (#92957)" (PR #98547)

2024-07-11 Thread Krystian Stasiowski via cfe-commits
https://github.com/sdkrystian closed https://github.com/llvm/llvm-project/pull/98547 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [libcxx] [llvm] Reapply "[Clang] Implement resolution for CWG1835 (#92957)" (PR #98547)

2024-07-11 Thread Krystian Stasiowski via cfe-commits
sdkrystian wrote: @chapuni This fixes the Ubuntu-20.04 g++ build issues you brought up in #98252. https://github.com/llvm/llvm-project/pull/98547 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[clang] [libcxx] [Clang] Implement resolution for CWG1835 (PR #92957)

2024-07-09 Thread Krystian Stasiowski via cfe-commits
https://github.com/sdkrystian closed https://github.com/llvm/llvm-project/pull/92957 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang][Sema] Handle class member access expressions with valid nested-name-specifiers that become invalid after lookup (PR #98167)

2024-07-09 Thread Krystian Stasiowski via cfe-commits
https://github.com/sdkrystian closed https://github.com/llvm/llvm-project/pull/98167 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang][Sema] Fix crash when rebuilding MemberExprs with invalid object expressions (PR #97455)

2024-07-09 Thread Krystian Stasiowski via cfe-commits
https://github.com/sdkrystian closed https://github.com/llvm/llvm-project/pull/97455 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang][Sema] Handle class member access expressions with valid nested-name-specifiers that become invalid after lookup (PR #98167)

2024-07-09 Thread Krystian Stasiowski via cfe-commits
sdkrystian wrote: @cor3ntin This fixes a bug introduced in this release, so I don't believe a release note is needed. https://github.com/llvm/llvm-project/pull/98167 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[clang] [Clang][Sema] Handle class member access expressions with valid nested-name-specifiers that become invalid after lookup (PR #98167)

2024-07-09 Thread Krystian Stasiowski via cfe-commits
https://github.com/sdkrystian edited https://github.com/llvm/llvm-project/pull/98167 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang][Sema] Handle class member access expressions with valid nested-name-specifiers that become invalid after lookup (PR #98167)

2024-07-09 Thread Krystian Stasiowski via cfe-commits
https://github.com/sdkrystian updated https://github.com/llvm/llvm-project/pull/98167 >From 57b79eb4ac71bfe13fbcece0c86ec0c9b7604494 Mon Sep 17 00:00:00 2001 From: Krystian Stasiowski Date: Tue, 9 Jul 2024 11:03:14 -0400 Subject: [PATCH] [Clang][Sema] Handle class member access expressions

[clang] [Clang][Sema] Handle class member access expressions with valid nested-name-specifiers that become invalid after lookup (PR #98167)

2024-07-09 Thread Krystian Stasiowski via cfe-commits
https://github.com/sdkrystian edited https://github.com/llvm/llvm-project/pull/98167 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang][Sema] Handle class member access expressions with valid nested-name-specifiers that become invalid after lookup (PR #98167)

2024-07-09 Thread Krystian Stasiowski via cfe-commits
https://github.com/sdkrystian created https://github.com/llvm/llvm-project/pull/98167 The following code causes [this assert](https://github.com/llvm/llvm-project/blob/main/clang/lib/Sema/SemaExprMember.cpp#L981) to fail: ```cpp struct A { }; struct B; void f(A *x) { x->B::y; // crash here

[clang] [Clang][Parse] Fix ambiguity with nested-name-specifiers that may declarative (PR #96364)

2024-07-09 Thread Krystian Stasiowski via cfe-commits
sdkrystian wrote: @mizvekov My initial implementation used the existing `UnannotatedTentativeParsingAction` implementation, but that had a _significant_ performance hit (7% vs 0.01%) compared to the new implementation. My new implementation of `UnannotatedTentativeParsingAction` is also more

[clang] [Clang][Index] Add support for dependent class scope explicit specializations of function templates to USRGenerator (PR #98027)

2024-07-08 Thread Krystian Stasiowski via cfe-commits
https://github.com/sdkrystian closed https://github.com/llvm/llvm-project/pull/98027 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang][Index] Add support for dependent class scope explicit specializations of function templates to USRGenerator (PR #98027)

2024-07-08 Thread Krystian Stasiowski via cfe-commits
https://github.com/sdkrystian created https://github.com/llvm/llvm-project/pull/98027 Given the following: ```cpp template struct A { void f(int); // #1 template void f(U); // #2 template<> void f(int); // #3 }; ``` Clang will generate the same USR for `#1` and

[clang] [Clang][Sema] Correctly transform dependent operands of overloaded binary operator& (PR #97596)

2024-07-03 Thread Krystian Stasiowski via cfe-commits
https://github.com/sdkrystian closed https://github.com/llvm/llvm-project/pull/97596 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang][Sema] Fix crash when rebuilding MemberExprs with invalid object expressions (PR #97455)

2024-07-03 Thread Krystian Stasiowski via cfe-commits
https://github.com/sdkrystian edited https://github.com/llvm/llvm-project/pull/97455 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang][Sema] Fix crash when rebuilding MemberExprs with invalid object expressions (PR #97455)

2024-07-03 Thread Krystian Stasiowski via cfe-commits
https://github.com/sdkrystian edited https://github.com/llvm/llvm-project/pull/97455 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang][Sema] Fix crash when rebuilding MemberExprs with invalid object expressions (PR #97455)

2024-07-03 Thread Krystian Stasiowski via cfe-commits
@@ -2896,6 +2896,9 @@ class TreeTransform { SS.Adopt(QualifierLoc); Base = BaseResult.get(); +if (Base->containsErrors()) + return ExprError(); sdkrystian wrote: @mizvekov The problems arise when we build a `MemberExpr` for a class member

[clang] [Clang][Sema] Correctly transform dependent operands of overloaded binary operator& (PR #97596)

2024-07-03 Thread Krystian Stasiowski via cfe-commits
https://github.com/sdkrystian updated https://github.com/llvm/llvm-project/pull/97596 >From d041273f56d59c9f466a9bb9a60b7501daa4844f Mon Sep 17 00:00:00 2001 From: Krystian Stasiowski Date: Wed, 3 Jul 2024 10:47:23 -0400 Subject: [PATCH 1/2] [Clang][Sema] Correctly transform dependent operands

[clang] [Clang][Sema] Treat explicit specializations of static data member templates declared without 'static' as static data members when diagnosing uses of 'auto' (PR #97425)

2024-07-03 Thread Krystian Stasiowski via cfe-commits
https://github.com/sdkrystian closed https://github.com/llvm/llvm-project/pull/97425 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang][Sema] Correctly transform dependent operands of overloaded binary operator& (PR #97596)

2024-07-03 Thread Krystian Stasiowski via cfe-commits
https://github.com/sdkrystian created https://github.com/llvm/llvm-project/pull/97596 Currently, `TreeTransform::TransformCXXOperatorCallExpr` calls `TreeTransform::TransformAddressOfOperand` to transform the first operand of a `CXXOperatorCallExpr` when its `OverloadOperatorKind` is `OO_Amp`

[clang] [Clang][Sema] Fix crash when rebuilding MemberExprs with invalid object expressions (PR #97455)

2024-07-02 Thread Krystian Stasiowski via cfe-commits
https://github.com/sdkrystian created https://github.com/llvm/llvm-project/pull/97455 Fixes #95778 >From 5eb3be349b8ca816bec672a6a423f28c4a50b63c Mon Sep 17 00:00:00 2001 From: Krystian Stasiowski Date: Tue, 2 Jul 2024 14:03:45 -0400 Subject: [PATCH] [Clang][Sema] Fix crash when rebuilding

[clang] [Clang][Sema] Diagnose variable template explicit specializations with storage-class-specifiers (PR #93873)

2024-07-02 Thread Krystian Stasiowski via cfe-commits
sdkrystian wrote: > I've been hinted though that Clang may be incorrect in accepting explicit > specializations of a templated static class data member in the class scope. > It looks like with all the restrictions in the standard it may only be > allowed to place explicit specializations of a

[clang] [Clang][Parse] Fix ambiguity with nested-name-specifiers that may declarative (PR #96364)

2024-07-02 Thread Krystian Stasiowski via cfe-commits
sdkrystian wrote: Ping @mizvekov @AaronBallman @cor3ntin https://github.com/llvm/llvm-project/pull/96364 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang][Sema] Diagnose variable template explicit specializations with storage-class-specifiers (PR #93873)

2024-07-02 Thread Krystian Stasiowski via cfe-commits
sdkrystian wrote: > non-static class member @alexfh Missed this one :) Opened a PR to fix this [here](https://github.com/llvm/llvm-project/pull/97425). https://github.com/llvm/llvm-project/pull/93873 ___ cfe-commits mailing list

[clang] [Clang][Sema] Treat explicit specializations of static data member templates declared without 'static' as static data members when diagnosing uses of 'auto' (PR #97425)

2024-07-02 Thread Krystian Stasiowski via cfe-commits
https://github.com/sdkrystian created https://github.com/llvm/llvm-project/pull/97425 After #93873 clang no longer permits declarations of explicit specializations of static data member templates to use the `auto` _placeholder-type-specifier_: ```cpp struct A { template static constexpr

[clang] [Clang][Sema] Fix lookup of dependent operator= named by using-declaration (PR #91503)

2024-06-28 Thread Krystian Stasiowski via cfe-commits
sdkrystian wrote: @pawosm-arm Could you provide some examples? Barring an issue with `operator=` which has been addressed, builds should only fail in the presence of accesses to non-existent members. Addressing such issues is the responsibility of users.

[clang] Clang: Add warning flag for storage class specifiers on explicit specializations (PR #96699)

2024-06-26 Thread Krystian Stasiowski via cfe-commits
https://github.com/sdkrystian approved this pull request. Minor nit: Probably don't need to explicitly define a diagnostic group, since it's only ever used for this diagnostic. https://github.com/llvm/llvm-project/pull/96699 ___ cfe-commits mailing

[clang] [Clang][Parse] Fix ambiguity with nested-name-specifiers that may declarative (PR #96364)

2024-06-21 Thread Krystian Stasiowski via cfe-commits
https://github.com/sdkrystian edited https://github.com/llvm/llvm-project/pull/96364 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang][Parse] Fix ambiguity with nested-name-specifiers that may declarative (PR #96364)

2024-06-21 Thread Krystian Stasiowski via cfe-commits
https://github.com/sdkrystian created https://github.com/llvm/llvm-project/pull/96364 Consider the following: ```cpp template struct A { }; template int A::B::* f(); // error: no member named 'B' in 'A' ``` Although this is clearly valid, clang rejects it because the _nested-name-specifier_

[clang] [Clang][Sema] Diagnose variable template explicit specializations with storage-class-specifiers (PR #93873)

2024-06-18 Thread Krystian Stasiowski via cfe-commits
https://github.com/sdkrystian closed https://github.com/llvm/llvm-project/pull/93873 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang][Sema] Diagnose variable template explicit specializations with storage-class-specifiers (PR #93873)

2024-06-18 Thread Krystian Stasiowski via cfe-commits
https://github.com/sdkrystian updated https://github.com/llvm/llvm-project/pull/93873 >From 40b69a190a1af610d946108394a38e3ac93dbd71 Mon Sep 17 00:00:00 2001 From: Krystian Stasiowski Date: Tue, 28 May 2024 07:42:06 -0400 Subject: [PATCH 1/5] [Clang][Sema] Diagnose variable template explicit

[clang] [Clang][Sema] Diagnose variable template explicit specializations with storage-class-specifiers (PR #93873)

2024-06-18 Thread Krystian Stasiowski via cfe-commits
https://github.com/sdkrystian updated https://github.com/llvm/llvm-project/pull/93873 >From 40b69a190a1af610d946108394a38e3ac93dbd71 Mon Sep 17 00:00:00 2001 From: Krystian Stasiowski Date: Tue, 28 May 2024 07:42:06 -0400 Subject: [PATCH 1/4] [Clang][Sema] Diagnose variable template explicit

[clang] [clang] always use resolved arguments for default argument deduction (PR #94756)

2024-06-07 Thread Krystian Stasiowski via cfe-commits
https://github.com/sdkrystian approved this pull request. LGTM https://github.com/llvm/llvm-project/pull/94756 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [libcxx] [Clang] Implement resolution for CWG1835 (PR #92957)

2024-06-06 Thread Krystian Stasiowski via cfe-commits
@@ -1442,19 +1442,27 @@ SourceLocation CXXUnresolvedConstructExpr::getBeginLoc() const { CXXDependentScopeMemberExpr::CXXDependentScopeMemberExpr( const ASTContext , Expr *Base, QualType BaseType, bool IsArrow, SourceLocation OperatorLoc, NestedNameSpecifierLoc

[clang] [libcxx] [Clang] Implement resolution for CWG1835 (PR #92957)

2024-06-06 Thread Krystian Stasiowski via cfe-commits
sdkrystian wrote: @erichkeane Hoping you can review this before your break! https://github.com/llvm/llvm-project/pull/92957 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Fixed grammatical error in "enum specifier" error msg #94443 (PR #94592)

2024-06-06 Thread Krystian Stasiowski via cfe-commits
@@ -6088,9 +6088,9 @@ def err_redefinition_different_concept : Error< "redefinition of concept %0 with different template parameters or requirements">; def err_tag_reference_non_tag : Error< "%select{non-struct type|non-class type|non-union type|non-enum " -

[clang] [libcxx] [Clang] Implement resolution for CWG1835 (PR #92957)

2024-06-04 Thread Krystian Stasiowski via cfe-commits
@@ -55,15 +55,21 @@ namespace PR11856 { template T *end(T*); - class X { }; + struct X { }; + struct Y { +int end; + }; template void Foo2() { T it1; -if (it1->end < it1->end) { -} +if (it1->end < it1->end) { } X *x; -if (x->end <

[clang] [clang] NFCI: remove obsolete workaround for template default arguments (PR #94311)

2024-06-04 Thread Krystian Stasiowski via cfe-commits
https://github.com/sdkrystian approved this pull request. LGTM https://github.com/llvm/llvm-project/pull/94311 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang] Implement resolution for CWG1835 (PR #92957)

2024-06-03 Thread Krystian Stasiowski via cfe-commits
sdkrystian wrote: This does seem to cause an error in libstdc++: ``` include/c++/11/bits/shared_ptr.h:365:10: error: use 'template' keyword to treat '__shared_ptr' as a dependent template name this->__shared_ptr<_Tp>::operator=(__r); ^ ``` Since `this` is dependent (it's of

[clang] [Clang] Implement resolution for CWG1835 (PR #92957)

2024-06-03 Thread Krystian Stasiowski via cfe-commits
https://github.com/sdkrystian edited https://github.com/llvm/llvm-project/pull/92957 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang] Implement resolution for CWG1835 (PR #92957)

2024-06-03 Thread Krystian Stasiowski via cfe-commits
sdkrystian wrote: > > Per [[basic.lookup.qual.general] > > p1](http://eel.is/c++draft/basic.lookup.qual.general#1), lookup for a > > member-qualified name is type-only if it's an identifier followed by ::; > > Per my reading, type-only lookup is performed only for elaborated type >

  1   2   3   4   5   6   7   8   >