[clang] Reapply "[Clang] Fix dependent local class instantiation bugs" (PR #135914)
llvm-ci wrote:
LLVM Buildbot has detected a new failure on builder `lldb-aarch64-ubuntu`
running on `linaro-lldb-aarch64-ubuntu` while building `clang` at step 6 "test".
Full details are available at:
https://lab.llvm.org/buildbot/#/builders/59/builds/16182
Here is the relevant piece of the build log for the reference
```
Step 6 (test) failure: build (failure)
...
PASS: lldb-api :: tools/lldb-server/TestGdbRemoteAttach.py (1201 of 2125)
UNSUPPORTED: lldb-api :: tools/lldb-server/TestGdbRemoteFork.py (1202 of 2125)
UNSUPPORTED: lldb-api :: tools/lldb-server/TestGdbRemoteForkResume.py (1203 of
2125)
UNSUPPORTED: lldb-api :: tools/lldb-server/TestGdbRemoteForkNonStop.py (1204 of
2125)
PASS: lldb-api :: tools/lldb-server/TestGdbRemoteCompletion.py (1205 of 2125)
PASS: lldb-api :: tools/lldb-server/TestGdbRemoteExitCode.py (1206 of 2125)
PASS: lldb-api :: tools/lldb-server/TestGdbRemoteHostInfo.py (1207 of 2125)
PASS: lldb-api :: tools/lldb-server/TestGdbRemoteModuleInfo.py (1208 of 2125)
PASS: lldb-api :: tools/lldb-server/TestGdbRemoteAuxvSupport.py (1209 of 2125)
UNRESOLVED: lldb-api :: tools/lldb-dap/variables/TestDAP_variables.py (1210 of
2125)
TEST 'lldb-api ::
tools/lldb-dap/variables/TestDAP_variables.py' FAILED
Script:
--
/usr/bin/python3.10
/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/llvm-project/lldb/test/API/dotest.py
-u CXXFLAGS -u CFLAGS --env
LLVM_LIBS_DIR=/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/./lib --env
LLVM_INCLUDE_DIR=/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/include
--env LLVM_TOOLS_DIR=/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/./bin
--arch aarch64 --build-dir
/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/lldb-test-build.noindex
--lldb-module-cache-dir
/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/lldb-test-build.noindex/module-cache-lldb/lldb-api
--clang-module-cache-dir
/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/lldb-test-build.noindex/module-cache-clang/lldb-api
--executable /home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/./bin/lldb
--compiler /home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/./bin/clang
--dsymutil /home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/./bin/dsymutil
--make /usr/bin/gmake --llvm-tools-dir
/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/./bin --lldb-obj-root
/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/tools/lldb --lldb-libs-dir
/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/./lib
/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/llvm-project/lldb/test/API/tools/lldb-dap/variables
-p TestDAP_variables.py
--
Exit Code: 1
Command Output (stdout):
--
lldb version 21.0.0git (https://github.com/llvm/llvm-project.git revision
d1a80deae674300d1011ccb6d6ee7030eaf8e713)
clang revision d1a80deae674300d1011ccb6d6ee7030eaf8e713
llvm revision d1a80deae674300d1011ccb6d6ee7030eaf8e713
Skipping the following test categories: ['libc++', 'dsym', 'gmodules',
'debugserver', 'objc']
--
Command Output (stderr):
--
UNSUPPORTED: LLDB
(/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/bin/clang-aarch64) ::
test_darwin_dwarf_missing_obj (TestDAP_variables.TestDAP_variables) (requires
one of macosx, darwin, ios, tvos, watchos, bridgeos, iphonesimulator,
watchsimulator, appletvsimulator)
UNSUPPORTED: LLDB
(/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/bin/clang-aarch64) ::
test_darwin_dwarf_missing_obj_with_symbol_ondemand_enabled
(TestDAP_variables.TestDAP_variables) (requires one of macosx, darwin, ios,
tvos, watchos, bridgeos, iphonesimulator, watchsimulator, appletvsimulator)
= DEBUG ADAPTER PROTOCOL LOGS =
1744872623.301907063 --> (stdin/stdout)
{"command":"initialize","type":"request","arguments":{"adapterID":"lldb-native","clientID":"vscode","columnsStartAt1":true,"linesStartAt1":true,"locale":"en-us","pathFormat":"path","supportsRunInTerminalRequest":true,"supportsVariablePaging":true,"supportsVariableType":true,"supportsStartDebuggingRequest":true,"supportsProgressReporting":true,"$__lldb_sourceInitFile":false},"seq":1}
1744872623.303959846 <-- (stdin/stdout) {"body":{"$__lldb_version":"lldb
version 21.0.0git (https://github.com/llvm/llvm-project.git revision
d1a80deae674300d1011ccb6d6ee7030eaf8e713)\n clang revision
d1a80deae674300d1011ccb6d6ee7030eaf8e713\n llvm revision
d1a80deae674300d1011ccb6d6ee7030eaf8e713","completionTriggerCharacters":[".","
","\t"],"exceptionBreakpointFilters":[{"default":false,"filter":"cpp_catch","label":"C++
Catch"},{"default":false,"filter":"cpp_throw","label":"C++
Throw"},{"default":false,"filter":"objc_catch","label":"Objective-C
Catch"},{"default":false,"filter":"objc_throw","label":"Objective-C
Throw"}],"supportTerminateDebuggee":true,"supportsBreakpointLocationsRequest":true,"supportsCancelRequest":true,"supportsCompletionsRequest":true,"supportsConditionalBreakpoints":true,"supportsConfigurationDoneRequest":true,"supportsDataB
[clang] Reapply "[Clang] Fix dependent local class instantiation bugs" (PR #135914)
https://github.com/zyn0217 closed https://github.com/llvm/llvm-project/pull/135914 ___ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Reapply "[Clang] Fix dependent local class instantiation bugs" (PR #135914)
zyn0217 wrote: > We're not really set up to run the full Fuchsia CI with specific upstream > patches, and it's a bit too flaky and expensive to be much good for that > anyway. For now, it's better as post-submit than pre-submit, I'm afraid. > > So long as this fixes the issue in the reproducer, and the LLVM tests pass, > that should be good enough to go in IMO. I tested the reproducer locally and it passed with this patch. Now that the CI is green, I'll go ahead and merge it - post-commit reviews are welcome https://github.com/llvm/llvm-project/pull/135914 ___ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Reapply "[Clang] Fix dependent local class instantiation bugs" (PR #135914)
https://github.com/zyn0217 updated
https://github.com/llvm/llvm-project/pull/135914
>From 7d39d1a66c171bc6e44742c0baea5bcab777bacd Mon Sep 17 00:00:00 2001
From: Younan Zhang
Date: Wed, 16 Apr 2025 13:27:54 +0800
Subject: [PATCH 1/3] Reapply "[Clang] Fix dependent local class instantiation
bugs"
---
clang/docs/ReleaseNotes.rst | 1 +
clang/lib/Sema/SemaTemplateInstantiate.cpp| 3 -
.../lib/Sema/SemaTemplateInstantiateDecl.cpp | 56 +++-
.../CodeGenCXX/local-class-instantiation.cpp | 64 +++
4 files changed, 120 insertions(+), 4 deletions(-)
create mode 100644 clang/test/CodeGenCXX/local-class-instantiation.cpp
diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 84ad253c1ec4f..87c2f72d20a46 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -458,6 +458,7 @@ Bug Fixes to C++ Support
by template argument deduction.
- Clang is now better at instantiating the function definition after its use
inside
of a constexpr lambda. (#GH125747)
+- Fixed a local class member function instantiation bug inside dependent
lambdas. (#GH59734), (#GH132208)
- Clang no longer crashes when trying to unify the types of arrays with
certain differences in qualifiers (this could happen during template argument
deduction or when building a ternary operator). (#GH97005)
diff --git a/clang/lib/Sema/SemaTemplateInstantiate.cpp
b/clang/lib/Sema/SemaTemplateInstantiate.cpp
index d2408a94ad0ab..0e81804f8c1e7 100644
--- a/clang/lib/Sema/SemaTemplateInstantiate.cpp
+++ b/clang/lib/Sema/SemaTemplateInstantiate.cpp
@@ -4126,9 +4126,6 @@ Sema::InstantiateClassMembers(SourceLocation
PointOfInstantiation,
if (FunctionDecl *Pattern =
Function->getInstantiatedFromMemberFunction()) {
-if (Function->isIneligibleOrNotSelected())
- continue;
-
if (Function->getTrailingRequiresClause()) {
ConstraintSatisfaction Satisfaction;
if (CheckFunctionConstraints(Function, Satisfaction) ||
diff --git a/clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
b/clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
index 5c80077f294c6..bf5a882ba4f12 100644
--- a/clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
+++ b/clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
@@ -5597,7 +5597,61 @@ void Sema::InstantiateFunctionDefinition(SourceLocation
PointOfInstantiation,
Function->setLocation(PatternDecl->getLocation());
Function->setInnerLocStart(PatternDecl->getInnerLocStart());
Function->setRangeEnd(PatternDecl->getEndLoc());
- Function->setDeclarationNameLoc(PatternDecl->getNameInfo().getInfo());
+ // Let the instantiation use the Pattern's DeclarationNameLoc, due to the
+ // following awkwardness:
+ //
+ // 1. There are out-of-tree users of getNameInfo().getSourceRange(), who
+ // expect the source range of the instantiated declaration to be set to
+ // point to the definition.
+ //
+ // 2. That getNameInfo().getSourceRange() might return the TypeLocInfo's
+ // location it tracked.
+ //
+ // 3. Function might come from an (implicit) declaration, while the pattern
+ // comes from a definition. In these cases, we need the PatternDecl's
source
+ // location.
+ //
+ // To that end, we need to more or less tweak the DeclarationNameLoc.
However,
+ // we can't blindly copy the DeclarationNameLoc from the PatternDecl to the
+ // function, since it contains associated TypeLocs that should have already
+ // been transformed. So, we rebuild the TypeLoc for that purpose.
Technically,
+ // we should create a new function declaration and assign everything we need,
+ // but InstantiateFunctionDefinition updates the declaration in place.
+ auto NameLocPointsToPattern = [&] {
+DeclarationNameInfo PatternName = PatternDecl->getNameInfo();
+DeclarationNameLoc PatternNameLoc = PatternName.getInfo();
+switch (PatternName.getName().getNameKind()) {
+case DeclarationName::CXXConstructorName:
+case DeclarationName::CXXDestructorName:
+case DeclarationName::CXXConversionFunctionName:
+ break;
+default:
+ // Cases where DeclarationNameLoc doesn't matter, as it merely contains a
+ // source range.
+ return PatternNameLoc;
+}
+
+TypeSourceInfo *TSI = Function->getNameInfo().getNamedTypeInfo();
+// TSI might be null if the function is named by a constructor template id.
+// E.g. S() {} for class template S with a template parameter T.
+if (!TSI) {
+ // We don't care about the DeclarationName of the instantiated function,
+ // but only the DeclarationNameLoc. So if the TypeLoc is absent, we do
+ // nothing.
+ return PatternNameLoc;
+}
+
+QualType InstT = TSI->getType();
+// We want to use a TypeLoc that reflects the transformed type while
+// preserving the source location from the pattern.
+TypeLocBuilder TLB;
+TLB.pushTrivial(
+Context, InstT,
+
[clang] Reapply "[Clang] Fix dependent local class instantiation bugs" (PR #135914)
@@ -347,7 +347,7 @@ ParsedType Sema::getDestructorName(const IdentifierInfo &II, QualType T = CheckTypenameType(ElaboratedTypeKeyword::None, SourceLocation(), SS.getWithLocInContext(Context), II, NameLoc); -return ParsedType::make(T); +return CreateParsedType(T, Context.getTrivialTypeSourceInfo(T, NameLoc)); zyn0217 wrote: Oh yeah, thanks! didn't notice that ;) https://github.com/llvm/llvm-project/pull/135914 ___ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Reapply "[Clang] Fix dependent local class instantiation bugs" (PR #135914)
https://github.com/zyn0217 updated
https://github.com/llvm/llvm-project/pull/135914
>From 7d39d1a66c171bc6e44742c0baea5bcab777bacd Mon Sep 17 00:00:00 2001
From: Younan Zhang
Date: Wed, 16 Apr 2025 13:27:54 +0800
Subject: [PATCH 1/3] Reapply "[Clang] Fix dependent local class instantiation
bugs"
---
clang/docs/ReleaseNotes.rst | 1 +
clang/lib/Sema/SemaTemplateInstantiate.cpp| 3 -
.../lib/Sema/SemaTemplateInstantiateDecl.cpp | 56 +++-
.../CodeGenCXX/local-class-instantiation.cpp | 64 +++
4 files changed, 120 insertions(+), 4 deletions(-)
create mode 100644 clang/test/CodeGenCXX/local-class-instantiation.cpp
diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 84ad253c1ec4f..87c2f72d20a46 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -458,6 +458,7 @@ Bug Fixes to C++ Support
by template argument deduction.
- Clang is now better at instantiating the function definition after its use
inside
of a constexpr lambda. (#GH125747)
+- Fixed a local class member function instantiation bug inside dependent
lambdas. (#GH59734), (#GH132208)
- Clang no longer crashes when trying to unify the types of arrays with
certain differences in qualifiers (this could happen during template argument
deduction or when building a ternary operator). (#GH97005)
diff --git a/clang/lib/Sema/SemaTemplateInstantiate.cpp
b/clang/lib/Sema/SemaTemplateInstantiate.cpp
index d2408a94ad0ab..0e81804f8c1e7 100644
--- a/clang/lib/Sema/SemaTemplateInstantiate.cpp
+++ b/clang/lib/Sema/SemaTemplateInstantiate.cpp
@@ -4126,9 +4126,6 @@ Sema::InstantiateClassMembers(SourceLocation
PointOfInstantiation,
if (FunctionDecl *Pattern =
Function->getInstantiatedFromMemberFunction()) {
-if (Function->isIneligibleOrNotSelected())
- continue;
-
if (Function->getTrailingRequiresClause()) {
ConstraintSatisfaction Satisfaction;
if (CheckFunctionConstraints(Function, Satisfaction) ||
diff --git a/clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
b/clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
index 5c80077f294c6..bf5a882ba4f12 100644
--- a/clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
+++ b/clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
@@ -5597,7 +5597,61 @@ void Sema::InstantiateFunctionDefinition(SourceLocation
PointOfInstantiation,
Function->setLocation(PatternDecl->getLocation());
Function->setInnerLocStart(PatternDecl->getInnerLocStart());
Function->setRangeEnd(PatternDecl->getEndLoc());
- Function->setDeclarationNameLoc(PatternDecl->getNameInfo().getInfo());
+ // Let the instantiation use the Pattern's DeclarationNameLoc, due to the
+ // following awkwardness:
+ //
+ // 1. There are out-of-tree users of getNameInfo().getSourceRange(), who
+ // expect the source range of the instantiated declaration to be set to
+ // point to the definition.
+ //
+ // 2. That getNameInfo().getSourceRange() might return the TypeLocInfo's
+ // location it tracked.
+ //
+ // 3. Function might come from an (implicit) declaration, while the pattern
+ // comes from a definition. In these cases, we need the PatternDecl's
source
+ // location.
+ //
+ // To that end, we need to more or less tweak the DeclarationNameLoc.
However,
+ // we can't blindly copy the DeclarationNameLoc from the PatternDecl to the
+ // function, since it contains associated TypeLocs that should have already
+ // been transformed. So, we rebuild the TypeLoc for that purpose.
Technically,
+ // we should create a new function declaration and assign everything we need,
+ // but InstantiateFunctionDefinition updates the declaration in place.
+ auto NameLocPointsToPattern = [&] {
+DeclarationNameInfo PatternName = PatternDecl->getNameInfo();
+DeclarationNameLoc PatternNameLoc = PatternName.getInfo();
+switch (PatternName.getName().getNameKind()) {
+case DeclarationName::CXXConstructorName:
+case DeclarationName::CXXDestructorName:
+case DeclarationName::CXXConversionFunctionName:
+ break;
+default:
+ // Cases where DeclarationNameLoc doesn't matter, as it merely contains a
+ // source range.
+ return PatternNameLoc;
+}
+
+TypeSourceInfo *TSI = Function->getNameInfo().getNamedTypeInfo();
+// TSI might be null if the function is named by a constructor template id.
+// E.g. S() {} for class template S with a template parameter T.
+if (!TSI) {
+ // We don't care about the DeclarationName of the instantiated function,
+ // but only the DeclarationNameLoc. So if the TypeLoc is absent, we do
+ // nothing.
+ return PatternNameLoc;
+}
+
+QualType InstT = TSI->getType();
+// We want to use a TypeLoc that reflects the transformed type while
+// preserving the source location from the pattern.
+TypeLocBuilder TLB;
+TLB.pushTrivial(
+Context, InstT,
+
[clang] Reapply "[Clang] Fix dependent local class instantiation bugs" (PR #135914)
mysterymath wrote: > @mysterymath In the meantime, can you please help us test the Fuchsia CI with > this patch? I appreciate your help :) We're not really set up to run the full Fuchsia CI with specific upstream patches, and it's a bit too flaky and expensive to be much good for that anyway. For now, it's better as post-submit than pre-submit, I'm afraid. So long as this fixes the issue in the reproducer, and the LLVM tests pass, that should be good enough to go in. https://github.com/llvm/llvm-project/pull/135914 ___ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Reapply "[Clang] Fix dependent local class instantiation bugs" (PR #135914)
@@ -347,7 +347,7 @@ ParsedType Sema::getDestructorName(const IdentifierInfo &II, QualType T = CheckTypenameType(ElaboratedTypeKeyword::None, SourceLocation(), SS.getWithLocInContext(Context), II, NameLoc); -return ParsedType::make(T); +return CreateParsedType(T, Context.getTrivialTypeSourceInfo(T, NameLoc)); mizvekov wrote: `CheckTypenameType` can produce a non-trivial type source info, there is an overload that has an out-parameter for that. https://github.com/llvm/llvm-project/pull/135914 ___ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Reapply "[Clang] Fix dependent local class instantiation bugs" (PR #135914)
https://github.com/erichkeane approved this pull request. https://github.com/llvm/llvm-project/pull/135914 ___ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Reapply "[Clang] Fix dependent local class instantiation bugs" (PR #135914)
zyn0217 wrote: @mysterymath In the meantime, can you please help us test the Fuchsia CI with this patch? I appreciate your help :) https://github.com/llvm/llvm-project/pull/135914 ___ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Reapply "[Clang] Fix dependent local class instantiation bugs" (PR #135914)
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: Younan Zhang (zyn0217)
Changes
This reapplies #134038
Since the last patch, this fixes a null pointer dereference where the TSI of
the destructor wasn't properly propagated into the DeclarationNameInfo. We now
construct a LocInfoType for dependent cases, as done elsewhere in
getDestructorName, such that GetTypeFromParser can correctly obtain the TSI.
Previous PR body:
This patch fixes two long-standing bugs that prevent Clang from instantiating
local class members inside a dependent context. These bugs were introduced in
commits
https://github.com/llvm/llvm-project/commit/21eb1af469c3257606aec2270d544e0e8ecf77b2
and
https://github.com/llvm/llvm-project/commit/919df9d75ac2a721a8072327c803f34486884571.
https://github.com/llvm/llvm-project/commit/21eb1af469c3257606aec2270d544e0e8ecf77b2
introduced a concept called eligible methods such that it did an attempt to
skip past ineligible method instantiation when instantiating class members.
Unfortunately, this broke the instantiation chain for local classes -
getTemplateInstantiationPattern() would fail to find the correct definition
pattern if the class was defined within a partially transformed dependent
context.
https://github.com/llvm/llvm-project/commit/919df9d75ac2a721a8072327c803f34486884571
introduced a separate issue by incorrectly copying the DeclarationNameInfo
during function definition instantiation from the template pattern, even though
that DNI might contain a transformed TypeSourceInfo. Since that TSI was already
updated when the declaration was instantiated, this led to inconsistencies. As
a result, the final instantiated function could lose track of the transformed
declarations, hence we crash: https://compiler-explorer.com/z/vjvoG76Tf.
This PR corrects them by
1. Removing the bypass logic for method instantiation. The eligible flag is
independent of instantiation and can be updated properly afterward, so skipping
instantiation is unnecessary.
2. Carefully handling TypeSourceInfo by creating a new instance that preserves
the pattern's source location while using the already transformed type.
---
Full diff: https://github.com/llvm/llvm-project/pull/135914.diff
6 Files Affected:
- (modified) clang/docs/ReleaseNotes.rst (+1)
- (modified) clang/lib/Sema/SemaExprCXX.cpp (+1-1)
- (modified) clang/lib/Sema/SemaTemplateInstantiate.cpp (-3)
- (modified) clang/lib/Sema/SemaTemplateInstantiateDecl.cpp (+55-1)
- (added) clang/test/CodeGenCXX/local-class-instantiation.cpp (+64)
- (modified) clang/test/SemaTemplate/instantiate-local-class.cpp (+34)
``diff
diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 84ad253c1ec4f..87c2f72d20a46 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -458,6 +458,7 @@ Bug Fixes to C++ Support
by template argument deduction.
- Clang is now better at instantiating the function definition after its use
inside
of a constexpr lambda. (#GH125747)
+- Fixed a local class member function instantiation bug inside dependent
lambdas. (#GH59734), (#GH132208)
- Clang no longer crashes when trying to unify the types of arrays with
certain differences in qualifiers (this could happen during template argument
deduction or when building a ternary operator). (#GH97005)
diff --git a/clang/lib/Sema/SemaExprCXX.cpp b/clang/lib/Sema/SemaExprCXX.cpp
index 8df590fa624cf..f83c05ac053ed 100644
--- a/clang/lib/Sema/SemaExprCXX.cpp
+++ b/clang/lib/Sema/SemaExprCXX.cpp
@@ -347,7 +347,7 @@ ParsedType Sema::getDestructorName(const IdentifierInfo &II,
QualType T =
CheckTypenameType(ElaboratedTypeKeyword::None, SourceLocation(),
SS.getWithLocInContext(Context), II, NameLoc);
-return ParsedType::make(T);
+return CreateParsedType(T, Context.getTrivialTypeSourceInfo(T, NameLoc));
}
// The remaining cases are all non-standard extensions imitating the behavior
diff --git a/clang/lib/Sema/SemaTemplateInstantiate.cpp
b/clang/lib/Sema/SemaTemplateInstantiate.cpp
index d2408a94ad0ab..0e81804f8c1e7 100644
--- a/clang/lib/Sema/SemaTemplateInstantiate.cpp
+++ b/clang/lib/Sema/SemaTemplateInstantiate.cpp
@@ -4126,9 +4126,6 @@ Sema::InstantiateClassMembers(SourceLocation
PointOfInstantiation,
if (FunctionDecl *Pattern =
Function->getInstantiatedFromMemberFunction()) {
-if (Function->isIneligibleOrNotSelected())
- continue;
-
if (Function->getTrailingRequiresClause()) {
ConstraintSatisfaction Satisfaction;
if (CheckFunctionConstraints(Function, Satisfaction) ||
diff --git a/clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
b/clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
index 5c80077f294c6..5f370c933f834 100644
--- a/clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
+++ b/clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
@@ -5597,7 +5597,61 @@ void Sema::InstantiateFunctionDefin
[clang] Reapply "[Clang] Fix dependent local class instantiation bugs" (PR #135914)
https://github.com/zyn0217 ready_for_review https://github.com/llvm/llvm-project/pull/135914 ___ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Reapply "[Clang] Fix dependent local class instantiation bugs" (PR #135914)
zyn0217 wrote: The Linux CI failure seems unrelated because I saw the same from @cor3ntin's PR: https://buildkite.com/llvm-project/github-pull-requests/builds/168960 https://github.com/llvm/llvm-project/pull/135914 ___ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Reapply "[Clang] Fix dependent local class instantiation bugs" (PR #135914)
https://github.com/zyn0217 edited https://github.com/llvm/llvm-project/pull/135914 ___ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Reapply "[Clang] Fix dependent local class instantiation bugs" (PR #135914)
https://github.com/zyn0217 created
https://github.com/llvm/llvm-project/pull/135914
This reapplies #134038
Since the last patch, this fixes a null pointer dereference where the TSI of
the destructor wasn't properly propagated into the DeclarationNameInfo. We now
construct a LocInfoType for dependent cases, as done elsewhere in
getDestructorName, such that GetTypeInfoFromParser can correctly obtain the TSI.
Previous PR body:
This patch fixes two long-standing bugs that prevent Clang from instantiating
local class members inside a dependent context. These bugs were introduced in
commits
https://github.com/llvm/llvm-project/commit/21eb1af469c3257606aec2270d544e0e8ecf77b2
and
https://github.com/llvm/llvm-project/commit/919df9d75ac2a721a8072327c803f34486884571.
https://github.com/llvm/llvm-project/commit/21eb1af469c3257606aec2270d544e0e8ecf77b2
introduced a concept called eligible methods such that it did an attempt to
skip past ineligible method instantiation when instantiating class members.
Unfortunately, this broke the instantiation chain for local classes -
getTemplateInstantiationPattern() would fail to find the correct definition
pattern if the class was defined within a partially transformed dependent
context.
https://github.com/llvm/llvm-project/commit/919df9d75ac2a721a8072327c803f34486884571
introduced a separate issue by incorrectly copying the DeclarationNameInfo
during function definition instantiation from the template pattern, even though
that DNI might contain a transformed TypeSourceInfo. Since that TSI was already
updated when the declaration was instantiated, this led to inconsistencies. As
a result, the final instantiated function could lose track of the transformed
declarations, hence we crash: https://compiler-explorer.com/z/vjvoG76Tf.
This PR corrects them by
1. Removing the bypass logic for method instantiation. The eligible flag is
independent of instantiation and can be updated properly afterward, so skipping
instantiation is unnecessary.
2. Carefully handling TypeSourceInfo by creating a new instance that preserves
the pattern's source location while using the already transformed type.
>From 7d39d1a66c171bc6e44742c0baea5bcab777bacd Mon Sep 17 00:00:00 2001
From: Younan Zhang
Date: Wed, 16 Apr 2025 13:27:54 +0800
Subject: [PATCH 1/2] Reapply "[Clang] Fix dependent local class instantiation
bugs"
---
clang/docs/ReleaseNotes.rst | 1 +
clang/lib/Sema/SemaTemplateInstantiate.cpp| 3 -
.../lib/Sema/SemaTemplateInstantiateDecl.cpp | 56 +++-
.../CodeGenCXX/local-class-instantiation.cpp | 64 +++
4 files changed, 120 insertions(+), 4 deletions(-)
create mode 100644 clang/test/CodeGenCXX/local-class-instantiation.cpp
diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 84ad253c1ec4f..87c2f72d20a46 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -458,6 +458,7 @@ Bug Fixes to C++ Support
by template argument deduction.
- Clang is now better at instantiating the function definition after its use
inside
of a constexpr lambda. (#GH125747)
+- Fixed a local class member function instantiation bug inside dependent
lambdas. (#GH59734), (#GH132208)
- Clang no longer crashes when trying to unify the types of arrays with
certain differences in qualifiers (this could happen during template argument
deduction or when building a ternary operator). (#GH97005)
diff --git a/clang/lib/Sema/SemaTemplateInstantiate.cpp
b/clang/lib/Sema/SemaTemplateInstantiate.cpp
index d2408a94ad0ab..0e81804f8c1e7 100644
--- a/clang/lib/Sema/SemaTemplateInstantiate.cpp
+++ b/clang/lib/Sema/SemaTemplateInstantiate.cpp
@@ -4126,9 +4126,6 @@ Sema::InstantiateClassMembers(SourceLocation
PointOfInstantiation,
if (FunctionDecl *Pattern =
Function->getInstantiatedFromMemberFunction()) {
-if (Function->isIneligibleOrNotSelected())
- continue;
-
if (Function->getTrailingRequiresClause()) {
ConstraintSatisfaction Satisfaction;
if (CheckFunctionConstraints(Function, Satisfaction) ||
diff --git a/clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
b/clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
index 5c80077f294c6..bf5a882ba4f12 100644
--- a/clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
+++ b/clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
@@ -5597,7 +5597,61 @@ void Sema::InstantiateFunctionDefinition(SourceLocation
PointOfInstantiation,
Function->setLocation(PatternDecl->getLocation());
Function->setInnerLocStart(PatternDecl->getInnerLocStart());
Function->setRangeEnd(PatternDecl->getEndLoc());
- Function->setDeclarationNameLoc(PatternDecl->getNameInfo().getInfo());
+ // Let the instantiation use the Pattern's DeclarationNameLoc, due to the
+ // following awkwardness:
+ //
+ // 1. There are out-of-tree users of getNameInfo().getSourceRange(), who
+ // expect the source range of the instan
