Hi,
On 08/07/2014 03:24 PM, Jason Merrill wrote:
On 08/07/2014 06:49 AM, Paolo Carlini wrote:
+ if (ENUM_UNDERLYING_TYPE (enumtype))
+ value = perform_implicit_conversion_flags
+ (ENUM_UNDERLYING_TYPE (enumtype), value, tf_warning_or_error,
+ LOOKUP_IMPLICIT | LOOKUP_NO_NARROWING);
It seems like doing this unconditionally will suppress this error in
some cases:
+ if (!int_fits_type_p (value, ENUM_UNDERLYING_TYPE
(enumtype)))
+ error ("enumerator value %E is outside the range of
underlying "
+ "type %<%T%>", value, ENUM_UNDERLYING_TYPE (enumtype));
Maybe only do the conversion above if the expression isn't already an
integer or enumeration?
If we do that, I have also to move back the latter check to the original
position, otherwise we regress, ie, we don't reject anymore, those two
testcases I tweaked. That means that when we are handling an enum with
fixed underlying type we always do that additional final check and
conversion, which, in my understanding, is redundant if we just call
perform_implicit_conversion_flags (with LOOKUP_NO_NARROWING!) on top.
Also, I was thinking earlier today that conceptually the check pasted
above should check cases different from the cases handled by
perform_implicit_conversion_flags, thus, eg, *not* handle enum27.C,
because it's an hard error, isn't our standard (and suppressible)
narrowing diagnostic. Seems more correct to use it only to diagnose that
the internally computed next enumerator overflows. See what I mean?
Thanks,
Paolo.
