`typeid()` does not yield a compile-time constant address

[llvmbot]

Bugzilla Link	20290
Version	3.4
OS	All
Reporter	LLVM Bugzilla Contributor
CC	@DougGregor,@zygoloid

Extended Description

static_assert ( & typeid( int ) == & typeid( int ), "" );

As far as I can see, this is valid C++11, and nothing changes for the latest C++14 draft. It does not include any id-expression, lvalue-to-rvalue conversion, nor a typeid with polymorphic operand.

Such a construct would provide value-based compile time type identity. GCC accepts it.

[ec04fc15-fa35-46f2-80e1-5d271f2ef708]

From my reply on std-proposals:

It is unspecified whether those two typeid expressions produce glvalues referring to the same object. Therefore this is "a relational or equality operator where the result is unspecified", so it's non-constant per 5.19/2 bullet 19.

Clang is not deliberately giving this result; I didn't think of this case when implementing support for typeid expressions in constexpr evaluation. Indeed, Clang gives the opposite result for this:

constexpr const std::type_info &x() { return typeid(int); } 
static_assert(&x() == &x(), "");

... which is arguably ill-formed for the same reason.

We should at least be consistent here; I've also mailed CWG to see if there's consensus for a less surprising rule here.