https://github.com/sdkrystian updated
https://github.com/llvm/llvm-project/pull/66636
>From 39744e6eb218ae519bcce83d90273296de496d94 Mon Sep 17 00:00:00 2001
From: Krystian Stasiowski
Date: Fri, 25 Aug 2023 14:07:32 -0400
Subject: [PATCH] [clang] remove ClassScopeFunctionSpecializationDecl
erichkeane wrote:
If Aaron doesn't get to it, feel free to ping me on Monday. Its too late on a
Friday for me to be able to merge this for you, but monday morning would be
fine for me.
https://github.com/llvm/llvm-project/pull/66636
___
cfe-commits
AaronBallman wrote:
Do you need someone to land these changes on your behalf?
https://github.com/llvm/llvm-project/pull/66636
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/sdkrystian updated
https://github.com/llvm/llvm-project/pull/66636
>From d11d546f3190936ba45c57b4825073026d817878 Mon Sep 17 00:00:00 2001
From: Krystian Stasiowski
Date: Fri, 25 Aug 2023 14:07:32 -0400
Subject: [PATCH 1/5] [clang] remove ClassScopeFunctionSpecializationDecl
https://github.com/AaronBallman approved this pull request.
LGTM aside from a minor suggestion with the release note.
https://github.com/llvm/llvm-project/pull/66636
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/66636
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
AaronBallman wrote:
CC @llvm/clang-vendors for awareness of the AST changing to remove a node.
https://github.com/llvm/llvm-project/pull/66636
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
sdkrystian wrote:
@AaronBallman
> Can you be sure to file an issue or add a test case + FIXME comment so we
> don't lose track of the needed follow-up work, or are you planning to do that
> work immediately after this lands?
I will address that once this gets merged
@@ -752,8 +745,6 @@ class CollectExtraHighlightings
}
if (auto *Args = D->getTemplateSpecializationArgsAsWritten())
H.addAngleBracketTokens(Args->getLAngleLoc(), Args->getRAngleLoc());
-if (auto *I = D->getDependentSpecializationInfo())
-
@@ -10442,32 +10441,54 @@ Sema::ActOnFunctionDeclarator(Scope *S, Declarator
, DeclContext *DC,
if (getLangOpts().CUDA && !isFunctionTemplateSpecialization)
maybeAddCUDAHostDeviceAttrs(NewFD, Previous);
-// If it's a friend (and only if it's a friend), it's
@@ -752,8 +745,6 @@ class CollectExtraHighlightings
}
if (auto *Args = D->getTemplateSpecializationArgsAsWritten())
H.addAngleBracketTokens(Args->getLAngleLoc(), Args->getRAngleLoc());
-if (auto *I = D->getDependentSpecializationInfo())
-
https://github.com/AaronBallman commented:
The changes should definitely have a release note so that downstreams can be
aware of the changes. This isn't really a potentially breaking change, but we
should alert clang-vendors in case a downstream actually cares.
@@ -9354,13 +9353,14 @@
Sema::CheckDependentFunctionTemplateSpecialization(FunctionDecl *FD,
}
F.done();
+ bool isFriend = FD->getFriendObjectKind() != Decl::FOK_None;
AaronBallman wrote:
```suggestion
bool IsFriend = FD->getFriendObjectKind() !=
@@ -1016,21 +1003,20 @@ void ASTDeclReader::VisitFunctionDecl(FunctionDecl *FD)
{
}
case FunctionDecl::TK_DependentFunctionTemplateSpecialization: {
// Templates.
-UnresolvedSet<8> TemplDecls;
-unsigned NumTemplates = Record.readInt();
-while
@@ -650,17 +642,16 @@ void ASTDeclWriter::VisitFunctionDecl(FunctionDecl *D) {
DependentFunctionTemplateSpecializationInfo *
DFTSInfo = D->getDependentSpecializationInfo();
-// Templates.
-Record.push_back(DFTSInfo->getNumTemplates());
-for (int i=0, e =
@@ -4086,7 +4073,7 @@ FunctionDecl
*Sema::SubstSpaceshipAsEqualEqual(CXXRecordDecl *RD,
Decl *R;
if (auto *MD = dyn_cast(Spaceship)) {
R = Instantiator.VisitCXXMethodDecl(
-MD, nullptr, std::nullopt,
+MD, nullptr,
shafik wrote:
@@ -650,17 +642,16 @@ void ASTDeclWriter::VisitFunctionDecl(FunctionDecl *D) {
DependentFunctionTemplateSpecializationInfo *
DFTSInfo = D->getDependentSpecializationInfo();
-// Templates.
-Record.push_back(DFTSInfo->getNumTemplates());
-for (int i=0, e =
https://github.com/shafik edited https://github.com/llvm/llvm-project/pull/66636
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -2154,6 +2144,15 @@ bool
RecursiveASTVisitor::TraverseFunctionHelper(FunctionDecl *D) {
TALI->NumTemplateArgs));
}
}
+// FIXME: Do we want to traverse the explicit template arguments for
@@ -10442,32 +10441,54 @@ Sema::ActOnFunctionDeclarator(Scope *S, Declarator
, DeclContext *DC,
if (getLangOpts().CUDA && !isFunctionTemplateSpecialization)
maybeAddCUDAHostDeviceAttrs(NewFD, Previous);
-// If it's a friend (and only if it's a friend), it's
@@ -185,14 +185,11 @@ namespace SameSignatureAfterInstantiation {
namespace PR22040 {
template struct Foobar {
-template <> void bazqux(typename T::type) {} // expected-error 2{{cannot
be used prior to '::' because it has no members}}
erichkeane
https://github.com/erichkeane commented:
I didn't spend much time in Serialization, so hopefully someone else can take a
look, but in general I think I'm warming toward this.
https://github.com/llvm/llvm-project/pull/66636
___
cfe-commits mailing
@@ -2154,6 +2144,15 @@ bool
RecursiveASTVisitor::TraverseFunctionHelper(FunctionDecl *D) {
TALI->NumTemplateArgs));
}
}
+// FIXME: Do we want to traverse the explicit template arguments for
@@ -428,6 +428,8 @@ class ASTNodeTraverser
void VisitFunctionDecl(const FunctionDecl *D) {
if (const auto *FTSI = D->getTemplateSpecializationInfo())
dumpTemplateArgumentList(*FTSI->TemplateArguments);
+else if (const auto *DFTSI =
@@ -10442,32 +10441,54 @@ Sema::ActOnFunctionDeclarator(Scope *S, Declarator
, DeclContext *DC,
if (getLangOpts().CUDA && !isFunctionTemplateSpecialization)
maybeAddCUDAHostDeviceAttrs(NewFD, Previous);
-// If it's a friend (and only if it's a friend), it's
sdkrystian wrote:
@erichkeane
> I guess my first question is 'why'?
Per the comment you mentioned, it is redundant. Switching to
`DependentFunctionTemplateSpecializationInfo` also results in constructs such
as:
```
template
struct A {
template<>
void f();
};
```
being diagnosed prior
cor3ntin wrote:
@erichkeane Opinions?
https://github.com/llvm/llvm-project/pull/66636
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/sdkrystian created
https://github.com/llvm/llvm-project/pull/66636
This removes the `ClassScopeFunctionSpecializationDecl` `Decl` node, and
instead uses `DependentFunctionTemplateSpecializationInfo` to handle such
declarations. `DependentFunctionTemplateSpecializationInfo`
28 matches
Mail list logo
