Re: [PATCH 0/3] enum_flags: Fix problems and add comprehensive unit tests

[Trevor Saunders <tbsaunde at tbsaunde dot org>]

On Fri, Nov 04, 2016 at 03:22:15AM +0000, Pedro Alves wrote:
> Recently, while working on making symfile_add_flags and objfile->flags
> strongly typed [1], I noticed a few enum_flags issues, like this
> failing to compile:
> 
>   symfile_add_flags add_flags = (SYMFILE_MAINLINE
>                                  | current_inferior ()->symfile_flags);
> 
> while the form that landed in master does compile:
> 
>   symfile_add_flags add_flags = (current_inferior ()->symfile_flags
>                                  | SYMFILE_MAINLINE);
>   
> This series started out by wanting to fix that, but it ended up fixing
> a bunch more, and adding comprehensive enum_flags unit tests along the
> way.  Writing the tests in turn exposed more problems.  Rinse, repeat.
> 
> The enum_flags methods and global operators are made constexpr where
> possible, and then C++11's deleted functions are used to remove
> overloads that should not compile.  The unit tests then build on
> SFINAE + decltype + constexpr to check that mixing enum flags types
> incorrectly would really fail to compile.
> 
> This series makes use of C++11 extensively: decltype, constexpr,
> =delete/=default, typedef -> type alias / using, static_assert, and
> more.

heh, I'm actually about to send patches adding enum-flags.h to include/
to use it in gcc which would mean supporting C++98.  It should be easy
to hide the constexpr and = delete stuff behind macros, but when we
merge these things I'm afraid we'll need to keep the underlying type
stuff, the typedefs and get rid of = default.  Given that there is still
plenty of C code around that we may want to convert to C++ at some point
supporting use in C code seems valueable to me.

Trev