[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 #4 from Simon Marchi <simon.marchi at polymtl dot ca> ---
(In reply to Tom Tromey from comment #2)
> I changed enum-flags.h to use std::underlying_type, with the idea
> that if there were any errors, I'd simply change the base
> enum to use an unsigned type.  (I tried auditing the existing
> uses by hand but I lost interest partway through.)

I think that the code explicitly avoids using underlying_type on the enum type,
to get around this behavior (I'll paste the code to generate this table at the
end).

Type             is_signed_v<T>      T(-1)  T(0)  T(-1) < T(0)
Implicit         false                  -1     0  true  
ExplicitSigned   true                   -1     0  true  
ExplicitUnsigned false          4294967295     0  false 

That is, an enum that doesn't specific a base type (Implicit above) has
unsigned underlying type, according to std::underlying_type, but it decays to
an integer, it appears to behave like a signed type (perhaps some language guru
can explain why).

The expression "T (-1) < T (0)" in enum-flags.h is ultimately used to defined
the traits type EnumIsUnsigned and EnumIsSigned.  And those are used to enable
or disable the use of operator~ on enum / enum flag types that behave like
signed types.  I guess because operator~ is not well-defined for them?

So by doing the std::underlying_type change, here's the difference.  Without
your change, trying to use operator~ on let's say STEP_OVER_BREAKPOINT would
give:

  CXX    infrun.o
/home/simark/src/binutils-gdb/gdb/infrun.c:1470:12: error: overload resolution
selected deleted operator '~'
  auto x = ~STEP_OVER_BREAKPOINT;
           ^~~~~~~~~~~~~~~~~~~~~
/home/simark/src/binutils-gdb/gdb/../gdbsupport/enum-flags.h:408:16: note:
candidate function [with enum_type = step_over_what_flag, $1 = void, $2 = void]
has been explicitly deleted
constexpr void operator~ (enum_type e) = delete;
               ^

If I change the enum_underlying_type definition to be:

template<typename T>
struct enum_underlying_type
{
  typedef typename integer_for_size<
    sizeof (T), static_cast<bool> (
                  std::is_signed_v<std::underlying_type_t<T>>)>::type type;
};

... then the use of operator~ is allowed.

I don't know if this complexity is needed in the end, I just wanted to explain
why (if I understand correctly) we have what we have today.

---

#include <fmt/core.h>
#include <sstream>

enum Implicit {
  A1 = 1,
  A2 = 2,
  A3 = 4,
};
enum ExplicitSigned : signed {
  B1 = 1,
  B2 = 2,
  B3 = 4,
};
enum ExplicitUnsigned : unsigned {
  C1 = 1,
  C2 = 2,
  C3 = 4,
};

template <typename T> void printInfosAboutT(const char *typeName) {
  fmt::print("{: <16} ", typeName);
  fmt::print("{: <14} ", std::is_signed_v<std::underlying_type_t<T>>);

  {
    std::ostringstream os;
    os << T(-1);
    fmt::print("{: >10}  ", os.str());
  }

  {
    std::ostringstream os;
    os << T(0);
    fmt::print("{: >4}  ", os.str());
  } 

  fmt::print("{: <5} ", T(-1) < T(0));
  fmt::print("\n");
}

int main() {
  fmt::print("Type             is_signed_v<T>      T(-1)  T(0)  T(-1) <
T(0)\n");
  printInfosAboutT<Implicit>("Implicit");
  printInfosAboutT<ExplicitSigned>("ExplicitSigned");
  printInfosAboutT<ExplicitUnsigned>("ExplicitUnsigned");
}

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