[Clang] Call to lambda expressions in unevaluated context is improperly rejected by Clang

[zyn0217]

I'm not confident that I'm summarizing the issue accurately, but here is an example of the case that I discovered while at #70601.

template <class T>
struct S {
  template <class U>
  using Type = decltype([]<class V> {
    return V();
  }.template operator()<U>());
};

S<int>::Type<int> V;

Clang currently rejects the above, complaining that there are no viable functions, which I think is suspicious.

<source>:6:14: error: no matching member function for call to 'operator()'
    4 |   using Type = decltype([]<class V> {
      |                         ~~~~~~~~~~~~~
    5 |     return V();
      |     ~~~~~~~~~~~
    6 |   }.template operator()<U>());
      |   ~~~~~~~~~~~^~~~~~~~~~~~~
<source>:9:9: note: in instantiation of template type alias 'Type' requested here
    9 | S<int>::Type<int> V;
      |         ^
<source>:4:25: note: candidate function template not viable: no known conversion from '(lambda at <source>:4:25)' to 'const S<int>::(lambda at <source>:4:25)' for object argument
    4 |   using Type = decltype([]<class V> {
      |                         ^
1 error generated.

The example is also on godbolt, and we can see that this is accepted by both MSVC and GCC.

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: Younan Zhang (zyn0217)

I'm not confident that I'm summarizing the issue accurately, but here is an example of the case that I discovered while at https://github.com//issues/70601. ```cpp template <class T> struct S { template <class U> using Type = decltype([]<class V> { return V(); }.template operator()<U>()); };

S<int>::Type<int> V;

Clang currently rejects the above, complaining that there are no viable functions, which I think is suspicious.

```txt
<source>:6:14: error: no matching member function for call to 'operator()'
    4 |   using Type = decltype([]<class V> {
      |                         ~~~~~~~~~~~~~
    5 |     return V();
      |     ~~~~~~~~~~~
    6 |   }.template operator()<U>());
      |   ~~~~~~~~~~~^~~~~~~~~~~~~
<source>:9:9: note: in instantiation of template type alias 'Type' requested here
    9 | S<int>::Type<int> V;
      |         ^
<source>:4:25: note: candidate function template not viable: no known conversion from '(lambda at <source>:4:25)' to 'const S<int>::(lambda at <source>:4:25)' for object argument
    4 |   using Type = decltype([]<class V> {
      |                         ^
1 error generated.

The example is also on godbolt, and we can see that this is accepted by both MSVC and GCC.

[zyn0217]

I've traced the error and found that the issue occurs when we finish the template argument deduction. At this point, we're in the callback of FinishTemplateArgumentDeduction, which eventually calls Sema::CheckNonDependentConversions.

We determine whether the argument type can be converted to the parameter type through some conversion sequences. Finally, we fail at this line in TryObjectArgumentInitialization. Looking around it, we can see that ClassTypeCanon and FromTypeCanon having different values, even though they both should point to the same Lambda type.

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

Lines 5729 to 5741 in 5452cbc

	// Check that we have either the same type or a derived type. It
	// affects the conversion rank.
	QualType ClassTypeCanon = S.Context.getCanonicalType(ClassType);
	ImplicitConversionKind SecondKind;
	if (ClassTypeCanon == FromTypeCanon.getLocalUnqualifiedType()) {
	SecondKind = ICK_Identity;
	} else if (S.IsDerivedFrom(Loc, FromType, ClassType)) {
	SecondKind = ICK_Derived_To_Base;
	} else if (!Method->isExplicitObjectMemberFunction()) {
	ICS.setBad(BadConversionSequence::unrelated_class,
	FromType, ImplicitParamType);
	return ICS;
	}

These two different types ought to correspond to the Lambda type before and after the TransformLambdaExpr. Looking back at the call stack, I found that both the ClassType and FromType stem from a CallExpr that has been transformed, and the callee of this CallExpr was an UnresolvedMemberExpr before the transformation. Following this clue, I entered TransformUnresolvedMemberExpr and found a suspicious point:

llvm-project/clang/lib/Sema/TreeTransform.h

Lines 14058 to 14091 in 5452cbc

	template <typename Derived>
	ExprResult TreeTransform<Derived>::TransformUnresolvedMemberExpr(
	UnresolvedMemberExpr *Old) {
	// Transform the base of the expression.
	ExprResult Base((Expr *)nullptr);
	QualType BaseType;
	if (!Old->isImplicitAccess()) {
	Base = getDerived().TransformExpr(Old->getBase());
	if (Base.isInvalid())
	return ExprError();
	Base =
	getSema().PerformMemberExprBaseConversion(Base.get(), Old->isArrow());
	if (Base.isInvalid())
	return ExprError();
	BaseType = Base.get()->getType();
	} else {
	BaseType = getDerived().TransformType(Old->getBaseType());
	}
	NestedNameSpecifierLoc QualifierLoc;
	if (Old->getQualifierLoc()) {
	QualifierLoc =
	getDerived().TransformNestedNameSpecifierLoc(Old->getQualifierLoc());
	if (!QualifierLoc)
	return ExprError();
	}
	SourceLocation TemplateKWLoc = Old->getTemplateKeywordLoc();
	LookupResult R(SemaRef, Old->getMemberNameInfo(), Sema::LookupOrdinaryName);
	// Transform the declaration set.
	if (TransformOverloadExprDecls(Old, /*RequiresADL*/ false, R))
	return ExprError();

There, we first try to convert the "BaseType", which is exactly this LambdaExpr. After that, we get a new CXXRecordDecl, along with an attached, transformed FunctionTemplateDecl. Then, we try to convert the DeclarationSet of this UnresolvedMemberExpr, where we eventually bake the untransformed FunctionTemplateDecl with the transformed CXXRecordType into a new UnresolvedMemberExpr.

This is the discrepancy that causes the problem above, where ClassTypeCanon actually comes from the DeclContext of the old FunctionTemplateDecl, which is the Lambda type before the transformation; while FromTypeCanon is the transformed CXXRecordType.

I've spent some hours fixing this, but I have no luck yet. The approach that makes sense to me is to have TransformUnresolvedMemberExpr get the correct DeclarationSet. This requires us to update TemplateInstantiator::TransformDecl, which is implemented by looking for instantiatedDecl in a LocalInstantiationScope. This raises another problem, as when we transform the LambdaExpr, we actually set up a distinct LocalInstantiationScope, which would be destroyed before we handle the UnresolvedMemberExpr.

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

Lines 1482 to 1488 in 0802596

	ExprResult TransformLambdaExpr(LambdaExpr *E) {
	LocalInstantiationScope Scope(SemaRef, /*CombineWithOuterScope=*/true);
	Sema::ConstraintEvalRAII<TemplateInstantiator> RAII(*this);
	ExprResult Result = inherited::TransformLambdaExpr(E);
	if (Result.isInvalid())
	return Result;

I tried to circumvent that by hoisting the LocalInstantiationScope into the TransformUnresolvedMemberExpr. The error then disappears, but unfortunately it brings me some regressions. I have no idea how to fix that so far, so I really appreciate it if someone could give me guidance!

Here is what I've done locally. #81150

CC @cor3ntin @erichkeane @AaronBallman

[MagentaTreehouse]

Possibly related issue: #76674

[jcsxky]

Possibly related issue: #76674

Not really. Root case of these two issues are different. Skip transformation causes #76674 and I have a patch to fix it(but i haven't merge into main since it may not an perfect fix and can't fix other related issues)

[zyn0217]

Not really. Root case of these two issues are different. Skip transformation causes #76674 and I have a patch to fix it(but i haven't merge into main since it may not an perfect fix and can't fix other related issues)

Oh, I have submitted a PR for these: #82310.