Hi,
On 08/07/2014 07:44 PM, Jason Merrill wrote:
On 08/07/2014 12:41 PM, Paolo Carlini wrote:
Ok. Probably at some point I should review which kind of diagnostics
the various implementations emit: for example *for enum27.C*
currently clang talks about *narrowing*, the kind of of diagnostics
we emit from chech_narrowing; EDG instead produces a something closer
to our error.
I saw that, too. There used to be a separate constraint "if the
initializing value of an enumerator cannot be represented by the
underlying type, the program is ill-formed" that was removed because
Richard Smith suggested it was redundant with the requirements for a
converted constant expression, but clang's current behavior suggests
that perhaps it wasn't so redundant...
I see, thanks. I wasn't aware of those events. Thus, does that mean that
maybe we should not use LOOKUP_NO_NARROWING outside, essentially, the
braced initializers context proper? However, a
LOOKUP_NO_NARROWING_OUTSIDE_BRACED_INITIALIZER would lead exactly to the
same code path and checks, only the actual diagnostic at the end of
check_narrowing would be different, an hard error instead of a pedwarn
and a wording like the one we have got now in the error message in
build_enumerator? Something I'm also thinking is that consistency in
this area is easier for clang, because, if I remember correctly, they
always have hard errors for narrowings and they don't print, as we do,
the final '... inside { }' text.
Thus, can you see a relatively easy way for us to have a better
consistency in the error messages, thus eg, same error/warning for:
struct X
{
constexpr operator int() const { return 768; }
constexpr int f() const { return 768; }
};
enum E : signed char { e1 = X(), e2 = X().f() };
???
Thanks!
Paolo.
PS: Finally, when/if we emit a clear hard error up front we should
probably also avoid the "overflow in implicit constant conversion"
warning. Certainly we don't emit it together with the error in
build_enumerator...
