[Bug gdb/31331] Wenum-constexpr-conversion should be fixed, soon treated as a hard error

["simon.marchi at polymtl dot ca" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=31331

--- Comment #16 from Simon Marchi <simon.marchi at polymtl dot ca> ---
(In reply to Carlos Galvez from comment #9)
> > If I change the enum_underlying_type definition to be:
> 
> That's exactly what I had in mind to change it to. You mention this change
> keeps the current behavior and the operator overload works as expected. Is
> there anything else that breaks?

So, with that change, for the enums that don't specify an underlying type,
enum_flags::underlying_type would go from a signed type to an unsigned one.

I didn't spot it at first, but another spot that uses the underlying type is
the definition of the binary bitwise operators, using this template:

https://gitlab.com/gnutools/binutils-gdb/-/blob/68d3bf7d246321407697aeb036036dae1a99a742/gdbsupport/enum-flags.h#L226-333

  /* Raw enum on both LHS/RHS.  Returns raw enum type.  */              \
  template <typename enum_type,                                         \
            typename = is_enum_flags_enum_type_t<enum_type>>            \
  constexpr enum_type                                                   \
  OPERATOR_OP (enum_type e1, enum_type e2)                              \
  {                                                                     \
    using underlying = typename enum_flags<enum_type>::underlying_type; \
    return (enum_type) (underlying (e1) OP underlying (e2));            \
  }                                                                     \

So we will cast the enum values to an unsigned type rather than a signed type
before applying the operator. I don't really see how things can go wrong with
that in practice.

-- 
You are receiving this mail because:
You are on the CC list for the bug.