clang doesn't instantiate constexpr functions where necessary during overload resolution

[efriedma-quic]

Bugzilla Link	11851
Resolution	FIXED
Resolved on	Nov 06, 2012 19:15
Version	unspecified
OS	All
CC	@jckarter,@DougGregor,@zygoloid

Extended Description

Testcase:

template constexpr int f() { return x; }
template void ovf(int (&x)[f()]);
void f() { int x[10]; ovf<10>(x); }

As far as I can tell, this is valid C++11.

[efriedma-quic]

assigned to @zygoloid

[llvmbot]

Here's another test case for, I think, the same bug:

$ cat test.ii
template
constexpr bool Integral() {
return true;
}
template<typename T, bool Int = Integral()>
struct safe_make_unsigned {
typedef T type;
};
template
using Make_unsigned = typename safe_make_unsigned::type;
template
struct get_distance_type {
using type = int;
};
template
auto size(R) -> Make_unsigned<typename get_distance_type::type>;
//bool b = Integral();
auto check() -> decltype(size(0));

$ clang++ -std=c++11 -fsyntax-only test.ii
test.ii:5:33: error: non-type template argument is not a constant expression
template<typename T, bool Int = Integral()>
^~~~~~~~~~~~~
test.ii:10:1: note: while checking a default template argument used here
using Make_unsigned = typename safe_make_unsigned::type;
^~~~~
test.ii:16:17: note: in instantiation of template type alias 'Make_unsigned'
requested here
auto size(R) -> Make_unsigned<typename get_distance_type::type>;
^
test.ii:16:6: note: while substituting deduced template arguments into function
template 'size' [with R = int]
auto size(R) -> Make_unsigned<typename get_distance_type::type>;
^
test.ii:5:33: note: undefined function 'Integral' cannot be used in a
constant expression
template<typename T, bool Int = Integral()>
^
test.ii:2:16: note: declared here
constexpr bool Integral() {
^
test.ii:18:26: error: no matching function for call to 'size'
auto check() -> decltype(size(0));
^~~~
test.ii:16:6: note: candidate template ignored: substitution failure
[with R = int]
auto size(R) -> Make_unsigned<typename get_distance_type::type>;
^
test.ii:18:1: error: 'auto' return without trailing return type
auto check() -> decltype(size(0));
^
3 errors generated.
$

I think it's the same bug because uncommenting the "bool b = Integral();" line to instantiate Integral makes the errors go away.

[zygoloid]

*** Bug llvm/llvm-bugzilla-archive#12288 has been marked as a duplicate of this bug. ***

[zygoloid]

*** Bug llvm/llvm-bugzilla-archive#13423 has been marked as a duplicate of this bug. ***

[llvmbot]

Ping?

[zygoloid]

*** Bug llvm/llvm-bugzilla-archive#13702 has been marked as a duplicate of this bug. ***

[llvmbot]

I was about to make a new bug report when I noticed this existing bug. To anyone experiencing this problem, a simple workaround is to add a level of indirection and put the call to the constexpr function inside of a template metafunction. This should temporarily solve all problems relating to the issue unless your constexpr function arguments are not valid template parameter types.

Anyway, here was my test case:

////////////////////
template< int > struct foo {};

template< class > constexpr int bar() { return 0; }

template< class T > foo< bar< T >() > foobar();

auto foobar_ = foobar< int >();
////////////////////

[zygoloid]

*** Bug llvm/llvm-bugzilla-archive#13970 has been marked as a duplicate of this bug. ***

[llvmbot]

Fix for issue 11851
This patch was written by Andrew Sutton and posted to the mailing list in March (http://lists.cs.uiuc.edu/pipermail/cfe-dev/2012-March/020308.html). I have simply rebased it onto the current git master branch of clang.

It fixes the issue and does not cause any regressions in the test-suite (on my system, x86-64 linux).

[zygoloid]

Another problem along the same lines (courtesy of llvm/llvm-bugzilla-archive#14203 ): an implicit special member is implicitly defined only when it's odr-used, so we reject this:

struct S {
constexpr S();
constexpr operator int() const { return 0; }
};
int k = sizeof(short{S(S())});

... because the implicit move constructor is not defined, so we can't see that the expression isn't narrowing.

[zygoloid]

Workaround
The attached patch works around this by forcing the instantiation or implicit definition of constexpr functions whenever possible (much like Andrew Sutton's patch). It has the same problem as that patch: it instantiates / defines such functions more often than the standard permits, and thus rejects some valid programs.

I'll try to get this into the 3.2 release if we don't have a better solution by that point.

[zygoloid]

Fixed, or at least worked around, in r167514. The core working group hasn't established a firm direction on how to behave here, but our behavior is now a very close match for g++'s.

[zygoloid]

mentioned in issue llvm/llvm-bugzilla-archive#12288

[zygoloid]

mentioned in issue llvm/llvm-bugzilla-archive#13423

[zygoloid]

mentioned in issue llvm/llvm-bugzilla-archive#13702