Missing FoundDecl in ConceptReference.

[hokein]

Given the following code, the FoundDecl is null in the Foo's AST node (ConceptReference).

namespace ns {
template<typename T> concept Foo = true;
}

using ns::Foo;
template<typename T>concept Bar = Foo<T>;  // reference `Foo` points to the underlying of ns::Foo, rather than the `using` decl.

This breaks some clang tools: include-cleaner will report the file of the underlying decl, rather than the one for using decl; clangd's go-to-def on Foo jumps to the underlying decl.

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: Haojian Wu (hokein)

Given the following code, the `FoundDecl` is null in the `Foo`'s AST node (`ConceptReference`).

namespace ns {
template<typename T> concept Foo = true;
}

using ns::Foo;
template<typename T>concept Bar = Foo<T>;  // reference `Foo` points to the underlying of ns::Foo, rather than the `using` decl.

This breaks some clang tools: include-cleaner will report the file of the underlying decl, rather than the one for using decl; clangd's go-to-def on Foo jumps to the underlying decl.

[zyn0217]

I think the reason is that LookupResult::getFoundDecl() returns the underlying Decl of the target UsingShadowDecl.

llvm-project/clang/include/clang/Sema/Lookup.h

Lines 563 to 567 in 1f6a347

	NamedDecl *getFoundDecl() const {
	assert(getResultKind() == Found
	&& "getFoundDecl called on non-unique result");
	return (*begin())->getUnderlyingDecl();
	}

llvm-project/clang/lib/Sema/SemaTemplate.cpp

Lines 5076 to 5080 in 1f6a347

	if (R.getAsSingle<ConceptDecl>()) {
	return CheckConceptTemplateId(SS, TemplateKWLoc, R.getLookupNameInfo(),
	R.getFoundDecl(),
	R.getAsSingle<ConceptDecl>(), TemplateArgs);
	}

Perhaps it should have been R.getRepresentativeDecl() based on the intent of ConceptReference::FoundDecl.

[zyn0217]

And applying that modification gives us the AST:

`-ConceptDecl 0x7fd5249c13c8 <line:6:1, col:40> col:29 Bar
  |-TemplateTypeParmDecl 0x7fd5249c1230 <col:10, col:19> col:19 referenced typename depth 0 index 0 T
  `-ConceptSpecializationExpr 0x7fd5249c1398 <col:35, col:40> 'bool' UsingShadow 0x7fd5249c11b0 'Foo'

compared to that before:

`-ConceptDecl 0x7fe2b920b298 <line:6:1, col:40> col:29 Bar
  |-TemplateTypeParmDecl 0x7fe2b920b100 <col:10, col:19> col:19 referenced typename depth 0 index 0 T
  `-ConceptSpecializationExpr 0x7fe2b920b268 <col:35, col:40> 'bool' Concept 0x7fe2b920afb0 'Foo'

[llvmbot]

@llvm/issue-subscribers-c-20

Author: Haojian Wu (hokein)

Given the following code, the `FoundDecl` is null in the `Foo`'s AST node (`ConceptReference`).

namespace ns {
template<typename T> concept Foo = true;
}

using ns::Foo;
template<typename T>concept Bar = Foo<T>;  // reference `Foo` points to the underlying of ns::Foo, rather than the `using` decl.

This breaks some clang tools: include-cleaner will report the file of the underlying decl, rather than the one for using decl; clangd's go-to-def on Foo jumps to the underlying decl.

[hokein]

@zyn0217 thanks for the investigation, it makes sense, do you mind sending out a fix?

[zyn0217]

Hmm, this is more complicated than I expected: for the type constraint cases, e.g.

namespace ns {
template<typename T> concept Foo = true;
}

using ns::Foo;

template <Foo T> // <-- Note here
void foo();

The FoundDecl thereof still doesn't point to the UsingShadowDecl that way, seemingly because the annotated token (which points to the UsingShadowDecl) gets desuagared implicitly within TemplateName::getAsTemplateDecl.

llvm-project/clang/lib/AST/TemplateName.cpp

Lines 145 to 152 in 597f976

	TemplateDecl *TemplateName::getAsTemplateDecl() const {
	if (Decl *TemplateOrUsing = Storage.dyn_cast<Decl *>()) {
	if (UsingShadowDecl *USD = dyn_cast<UsingShadowDecl>(TemplateOrUsing))
	return cast<TemplateDecl>(USD->getTargetDecl());
	assert(isa<TemplateDecl>(TemplateOrUsing));
	return cast<TemplateDecl>(TemplateOrUsing);
	}

llvm-project/clang/lib/Sema/SemaTemplate.cpp

Lines 1145 to 1177 in 597f976

	bool Sema::BuildTypeConstraint(const CXXScopeSpec &SS,
	TemplateIdAnnotation *TypeConstr,
	TemplateTypeParmDecl *ConstrainedParameter,
	SourceLocation EllipsisLoc,
	bool AllowUnexpandedPack) {
	if (CheckTypeConstraint(TypeConstr))
	return true;
	TemplateName TN = TypeConstr->Template.get();
	ConceptDecl *CD = cast<ConceptDecl>(TN.getAsTemplateDecl());
	DeclarationNameInfo ConceptName(DeclarationName(TypeConstr->Name),
	TypeConstr->TemplateNameLoc);
	TemplateArgumentListInfo TemplateArgs;
	if (TypeConstr->LAngleLoc.isValid()) {
	TemplateArgs =
	makeTemplateArgumentListInfo(*this, *TypeConstr);
	if (EllipsisLoc.isInvalid() && !AllowUnexpandedPack) {
	for (TemplateArgumentLoc Arg : TemplateArgs.arguments()) {
	if (DiagnoseUnexpandedParameterPack(Arg, UPPC_TypeConstraint))
	return true;
	}
	}
	}
	return AttachTypeConstraint(
	SS.isSet() ? SS.getWithLocInContext(Context) : NestedNameSpecifierLoc(),
	ConceptName, CD,
	TypeConstr->LAngleLoc.isValid() ? &TemplateArgs : nullptr,
	ConstrainedParameter, EllipsisLoc);
	}

[zyn0217]

The type constraint cases are not that hard to tackle, but constraints on AutoTypes e.g. C auto probably need some extra work.

(I hope I can figure them all out, but it takes some time.)