Re: [C++ Patch] PR 51312

[Paolo Carlini <paolo dot carlini at oracle dot com>]

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...