Clang 19 regression: "error: function 'operator()' with deduced return type cannot be used before it is defined"

[porglezomp]

The following code, based on Barry Revzin's recursive lambda recommendations and reduced from some actual software, compiles with Clang 18.1 but fails with Clang 19.

• ❌ Clang (trunk): https://godbolt.org/z/79hKhaKx3 (Using 14f745074d05fb42f5c8a625c79bf557bb980ebb)
• ✅ Clang 18.1: https://godbolt.org/z/cvEWEsEd8

#include <utility>

template <typename F> struct recursive_lambda {
    template <typename... Args> auto operator()(Args&&... args) const { return fn(*this, std::forward<Args>(args)...); }
    F fn;
};

template <typename F> recursive_lambda(F) -> recursive_lambda<F>;

struct Tree { Tree *left, *right; };

int sumSize(Tree *tree) {
    auto accumulate = recursive_lambda {
        [&](auto& self_fn, Tree *element_node) -> int {
	    if (!tree) return 0;
	    return 1 + self_fn(tree->left) + self_fn(tree->right);
        }
    };

    return accumulate(tree);
}

Fails with:

<source>:19:17: error: function 'operator()<Tree *&>' with deduced return type cannot be used before it is defined
   19 |             return 1 + self_fn(tree->left) + self_fn(tree->right);
      |                        ^
<source>:4:80: note: in instantiation of function template specialization 'sumSize(Tree *)::(anonymous class)::operator()<const recursive_lambda<(lambda at <source>:17:9)>>' requested here
    4 |     template <typename... Args> auto operator()(Args&&... args) const { return fn(*this, std::forward<Args>(args)...); }
      |                                                                                ^
<source>:23:22: note: in instantiation of function template specialization 'recursive_lambda<(lambda at <source>:17:9)>::operator()<Tree *&>' requested here
   23 |     return accumulate(tree);
      |                      ^
<source>:4:38: note: 'operator()<Tree *&>' declared here
    4 |     template <typename... Args> auto operator()(Args&&... args) const { return fn(*this, std::forward<Args>(args)...); }
      |                                      ^

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: Cassie Jones (porglezomp)

The following code, based on Barry Revzin's recursive lambda recommendations and reduced from some actual software, compiles with Clang 18.1 but fails with Clang 19.

• ❌ Clang (trunk): https://godbolt.org/z/79hKhaKx3 (Using 14f745074d05fb42f5c8a625c79bf557bb980ebb)
• ✅ Clang 18.1: https://godbolt.org/z/cvEWEsEd8

#include <utility>

template <typename F> struct recursive_lambda {
    template <typename... Args> auto operator()(Args&&... args) const { return fn(*this, std::forward<Args>(args)...); }
    F fn;
};

template <typename F> recursive_lambda(F) -> recursive_lambda<F>;

struct Tree { Tree *left, *right; };

int sumSize(Tree *tree) {
    auto accumulate = recursive_lambda {
        [&](auto& self_fn, Tree *element_node) -> int {
	    if (!tree) return 0;
	    return 1 + self_fn(tree->left) + self_fn(tree->right);
        }
    };

    return accumulate(tree);
}

[cor3ntin]

This is caused by #95660
@zyn0217 Could you take a look?

[cor3ntin]

See also #97680

[porglezomp]

Hm, this specific case appears to be a Clang 19 regression but I see this earlier issue ended up getting reduced to something giving an identical diagnostic, back in Clang 16? #61866 (comment)

[porglezomp]

Re: #95660—I'm not sure about that diagnosis, I've reverted that locally and I'm still seeing the failure.

[zyn0217]

I'm looking into this.

[zyn0217]

So this is indeed a regression caused by #95660.

The issue is that instantiating recursive_lambda::operator() would entail the instantiation of fn(), the local lambda. Before #95660, we were deferring the instantiation of such lambdas (specifically, function template defined within local classes), and hence, we wouldn't have to visit the lambda body. After my patch, all constexpr lambdas are instantiated eagerly, and in this situation, the instantiation of lambda would also recursively instantiate self_fn which is actually recursive_lambda::operator(), hence the error.

This is actually a problem of the timing of eagerly instantiating local lambdas and the appropriate context for doing so. Clearly, for this case, this is where we should hold off the lambda instantiation, while in that motivating case, it is not. I think a fix would be to revert the changes in #95660, and instead, we instantiate such lambdas if they're involved in a constant evaluation.