[clang] [clang] return type not correctly deduced for discarded lambdas (PR #153921)

[Oliver Hunt via cfe-commits]

ojhunt wrote:

> This should work
> 
> ```diff
> diff --git a/clang/lib/Sema/SemaTemplateInstantiateDecl.cpp b/clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
> index f02a295220ef..6b423ce06523 100644
> --- a/clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
> +++ b/clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
> @@ -5669,7 +5669,7 @@ void Sema::InstantiateFunctionDefinition(SourceLocation PointOfInstantiation,
>    };
>    Function->setDeclarationNameLoc(NameLocPointsToPattern());
>  
> -  EnterExpressionEvaluationContext EvalContext(
> +  EnterExpressionEvaluationContextForFunction EvalContext(
>        *this, Sema::ExpressionEvaluationContext::PotentiallyEvaluated);
>  
>    Qualifiers ThisTypeQuals;
> ```

@cor3ntin  One thing I'm trying to work out in tests is whether there is any way to get a discarded block that should cause an error in the containing scope but not if it occurred in the lamda instantiation.

e.g a hypothetical

```cpp
auto lambda = [x=some expression](type/auto foo = some expression, ..) requires { something } {
 ..
 /* I want to be able to construct an equivalent to this, that can live in the above
  * capture, default, or constraint contexts
  */
 if constexpr (0) {
    // some error that won't break the compilation
 }
};
```

The problem is I can never work out what kind of discarded statements or expressions permit an error to exist without resulting in an actual compilation error.

I am also very sad we no longer allow statement expressions in parameter default expressions. I mean from a language point of view that's obviously the right thing as the old behavior could result in insanity, but from the point of view of trying to make insane test cases it's annoying :D



https://github.com/llvm/llvm-project/pull/153921