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

Luis Machado
2016-11-07T13:33:42Z

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.