This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [C++ Patch] PR 51312


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]