Missing "no return statement in constexpr function" error for a templated constexpr function

[strimo378]

Hi all,

I found a case where clang issues a warning about "non-void function does not return a value" for a constexpr function. For constexpr function, clang typically issues an error and no warning.

The code to generate the warning is

template <class...> struct a {};
template <class... b> constexpr a<typename b ::c...> d() {}
auto e = d();

//constexpr int f() {}

Or a link to compiler explorer https://godbolt.org/z/1rd4W8exr

[llvmbot]

@llvm/issue-subscribers-clang-frontend

[tbaederr]

I think the warning (instead of an error) is warranted unless the function is actually used. @cjdb, @AaronBallman?

[Fznamznon]

I think the warning (instead of an error) is warranted unless the function is actually used.

But it is used in the example.

[tbaederr]

Right, I was thinking more in the sense of https://godbolt.org/z/Txhhr9bf3

[cor3ntin]

I don't think the fact the function is constexpr should have any effect on diagnostics here,
given that constexpr functions are no longer required to be callable in a constant evaluated context, per P2448 which remove that requirement as a DR
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2448r2.html#pnum_24

Then the question of whether it should always be ill-formed, like MSVC? Maybe because it's always a (rather nasty) bug,
but it would be a rather large change

[shafik]

I agree with @cor3ntin here, I think this would only be ill-formed if we use this in a constant expression context.

[AaronBallman]

I don't think the fact the function is constexpr should have any effect on diagnostics here,

Agreed as well; the original example is not calling d() in a constant evaluation context. If you add constexpr in front of auto e then you'll get the expected diagnostic. That you can never call that function in a constexpr context but it's not an error just to define it that way is what WG21 wanted. We currently have partial support for P2448 (https://clang.llvm.org/cxx_status.html) which implements those changes.

I think we should handle both cases consistently and either allow foo() (only fail when foo() is called in a constexpr context) or disallow d(). GCC rejects both, MSVC and Clang only reject foo(), and ICC/EDG accepts both. Personally, I prefer the GCC approach of rejecting both -- there's no way to call that function in a constexpr context or otherwise that doesn't result in problems.

[strimo378]

Hi all,

I found another case with different warning/error behavior between templated and non-templated code in clang. Just uncomment the template line to produce an error:

struct a {
  a(int);
};

// template <class = int> 
struct b : a {
  constexpr b() : a(int()) {}
};
b c;

See https://godbolt.org/z/5Gf5Yo3G8