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

[Luis Machado <lgustavo@codesourcery.com>]

On 11/03/2016 10:22 PM, 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.
>
> [1] https://sourceware.org/ml/gdb-patches/2016-10/msg00715.html
>
> Pedro Alves (3):
>   enum_flags: Use C++11 std::underlying_type
>   enum_flags: Fix problems and add comprehensive unit tests
>   enum_flags: Fix ternary operator and remove implicit convertion to raw
>     enum
>
>  gdb/Makefile.in               |   2 +-
>  gdb/btrace.c                  |   4 +-
>  gdb/common/enum-flags.h       | 251 ++++++++++++-------
>  gdb/compile/compile-c-types.c |   2 +-
>  gdb/enum-flags-selftests.c    | 557 ++++++++++++++++++++++++++++++++++++++++++
>  gdb/go-exp.y                  |   2 +-
>  gdb/record-btrace.c           |  10 +-
>  gdb/selftest.h                |  11 +
>  8 files changed, 738 insertions(+), 101 deletions(-)
>  create mode 100644 gdb/enum-flags-selftests.c
>

It is a bit more general, but i thought i'd throw this out there. Do we 
have a policy for new unit tests, how they should be created and if/when 
they should be a replacement for .exp tests?

Anything that gets us further away from dejagnu/expect-based testing is 
a win in my opinion. If we can get unit tests to cover part or most of 
that, even better.