aboutsummaryrefslogtreecommitdiff
path: root/gdb/unittests/enum-flags-selftests.c
AgeCommit message (Collapse)AuthorFilesLines
2024-12-22Fix -Wenum-constexpr-conversion in enum-flags.hCarlos Galvez1-27/+0
This fixes PR 31331: https://sourceware.org/bugzilla/show_bug.cgi?id=31331 Currently, enum-flags.h is suppressing the warning -Wenum-constexpr-conversion coming from recent versions of Clang. This warning is intended to be made a compiler error (non-downgradeable) in future versions of Clang: https://github.com/llvm/llvm-project/issues/59036 The rationale is that casting a value of an integral type into an enumeration is Undefined Behavior if the value does not fit in the range of values of the enum: https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1766 Undefined Behavior is not allowed in constant expressions, leading to an ill-formed program. In this case, in enum-flags.h, we are casting the value -1 to an enum of a positive range only, which is UB as per the Standard and thus not allowed in a constexpr context. The purpose of doing this instead of using std::underlying_type is because, for C-style enums, std::underlying_type typically returns "unsigned int". However, when operating with it arithmetically, the enum is promoted to *signed* int, which is what we want to avoid. This patch solves this issue as follows: * Use std::underlying_type and remove the custom enum_underlying_type. * Ensure that operator~ is called always on an unsigned integer. We do this by casting the input enum into std::size_t, which can fit any unsigned integer. We have the guarantee that the cast is safe, because we have checked that the underlying type is unsigned. If the enum had negative values, the underlying type would be signed. This solves the issue with C-style enums, but also solves a hidden issue: enums with underlying type of std::uint8_t or std::uint16_t are *also* promoted to signed int. Now they are all explicitly casted to the largest unsigned int type and operator~ is safe to use. * There is one more thing that needs fix. Currently, operator~ is implemented as follows: return (enum_type) ~underlying(e); After applying ~underlying(e), the result is a very large value, which we then cast to "enum_type". This cast is Undefined Behavior if the large value does not fit in the range of the enum. For C++ enums (scoped and/or with explicit underlying type), the range of the enum is the entire range of the underlying type, so the cast is safe. However, for C-style enums, the range is the smallest bit-field that can hold all the values of the enumeration. So the range is a lot smaller and casting a large value to the enum would invoke Undefined Behavior. To solve this problem, we create a new trait EnumHasFixedUnderlyingType, to ensure operator~ may only be called on C++-style enums. This behavior is roughly the same as what we had on trunk, but relying on different properties of the enums. * Once this is implemented, the following tests fail to compile: CHECK_VALID (true, int, true ? EF () : EF2 ()) This is because it expects the enums to be promoted to signed int, instead of unsigned int (which is the true underlying type). I propose to remove these tests altogether, because: - The comment nearby say they are not very important. - Comparing 2 enums of different type like that is strange, relies on integer promotions and thus hurts readability. As per comments in the related PR, we likely don't want this type of code in gdb code anyway, so there's no point in testing it. - Most importantly, this type of comparison will be ill-formed in C++26 for regular enums, so enum_flags does not need to emulate that. Since this is the only place where the warning was suppressed, remove also the corresponding macro in include/diagnostics.h. The change has been tested by running the entire gdb test suite (make check) and comparing the results (testsuite/gdb.sum) against trunk. No noticeable differences have been observed. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31331 Tested-by: Keith Seitz <keiths@redhat.com> Approved-By: Tom Tromey <tom@tromey.com>
2024-08-12gdb: change names of enumerations in enum flags selftestSimon Marchi1-151/+153
When reading this test (in the context of PR 31331), I had trouble understanding the tests, because of the abbreviated names. I would prefer if the names were a bit more explicit, like this. Change-Id: I85669b238a9d5dacf673a7bbfc1ca18f80d2b2cf
2024-08-12gdb, gdbsupport: use `using` in enum flags codeSimon Marchi1-2/+2
I think that `using` is easier to read than `typedef`, and it's the modern C++ thing anyway. Change-Id: Iccb62dc3869cddfb6a684ef3023dcd5b799f3ab2
2024-03-26gdb, gdbserver, gdbsupport: remove includes of early headersSimon Marchi1-1/+0
Now that defs.h, server.h and common-defs.h are included via the `-include` option, it is no longer necessary for source files to include them. Remove all the inclusions of these files I could find. Update the generation scripts where relevant. Change-Id: Ia026cff269c1b7ae7386dd3619bc9bb6a5332837 Approved-By: Pedro Alves <pedro@palves.net>
2024-02-21gdbsupport: assume that compiler supports ↵Simon Marchi1-4/+0
std::{is_trivially_constructible,is_trivially_copyable} This code was there to support g++ 4, which didn't support std::is_trivially_constructible and std::is_trivially_copyable. Since we now require g++ >= 9, I think it's fair to assume that GDB will always be compiled with a compiler that supports those. Change-Id: Ie7c1649139a2f48bf662cac92d7f3e38fb1f1ba1
2024-02-21gdb: remove some GCC version checksSimon Marchi1-6/+0
Since we now require C++17, and therefore gcc >= 9, it's no longer useful to have gcc version checks for older gcc version. Change-Id: I3a87baa03c475f2b847b422b16b69c5ff7215b54 Reviewed-by: Kevin Buettner <kevinb@redhat.com> Approved-By: Pedro Alves <pedro@palves.net>
2024-01-12Update copyright year range in header of all files managed by GDBAndrew Burgess1-1/+1
This commit is the result of the following actions: - Running gdb/copyright.py to update all of the copyright headers to include 2024, - Manually updating a few files the copyright.py script told me to update, these files had copyright headers embedded within the file, - Regenerating gdbsupport/Makefile.in to refresh it's copyright date, - Using grep to find other files that still mentioned 2023. If these files were updated last year from 2022 to 2023 then I've updated them this year to 2024. I'm sure I've probably missed some dates. Feel free to fix them up as you spot them.
2023-11-29Remove gdb_static_assertTom Tromey1-23/+23
C++17 makes the second parameter to static_assert optional, so we can remove gdb_static_assert now.
2023-01-30enum_flags to_stringPedro Alves1-6/+63
This commit introduces shared infrastructure that can be used to implement enum_flags -> to_string functions. With this, if we want to support converting a given enum_flags specialization to string, we just need to implement a function that provides the enumerator->string mapping, like so: enum some_flag { SOME_FLAG1 = 1 << 0, SOME_FLAG2 = 1 << 1, SOME_FLAG3 = 1 << 2, }; DEF_ENUM_FLAGS_TYPE (some_flag, some_flags); static std::string to_string (some_flags flags) { static constexpr some_flags::string_mapping mapping[] = { MAP_ENUM_FLAG (SOME_FLAG1), MAP_ENUM_FLAG (SOME_FLAG2), MAP_ENUM_FLAG (SOME_FLAG3), }; return flags.to_string (mapping); } .. and then to_string(SOME_FLAG2 | SOME_FLAG3) produces a string like "0x6 [SOME_FLAG2 SOME_FLAG3]". If we happen to forget to update the mapping array when we introduce a new enumerator, then the string representation will pretty-print the flags it knows about, and then the leftover flags in hex (one single number). For example, if we had missed mapping SOME_FLAG2 above, we'd end up with: to_string(SOME_FLAG2 | SOME_FLAG3) => "0x6 [SOME_FLAG2 0x4]"); Other than in the unit tests included, no actual usage of the functionality is added in this commit. Approved-By: Simon Marchi <simon.marchi@efficios.com> Change-Id: I835de43c33d13bc0c95132f42c3f97318b875779
2023-01-01Update copyright year range in header of all files managed by GDBJoel Brobecker1-1/+1
This commit is the result of running the gdb/copyright.py script, which automated the update of the copyright year range for all source files managed by the GDB project to be updated to include year 2023.
2022-01-01Automatic Copyright Year update after running gdb/copyright.pyJoel Brobecker1-1/+1
This commit brings all the changes made by running gdb/copyright.py as per GDB's Start of New Year Procedure. For the avoidance of doubt, all changes in this commits were performed by the script.
2021-01-01Update copyright year range in all GDB filesJoel Brobecker1-1/+1
This commits the result of running gdb/copyright.py as per our Start of New Year procedure... gdb/ChangeLog Update copyright year range in copyright header of all GDB files.
2020-09-29Tweak gdbsupport/valid-expr.h for GCC 6, fix buildPedro Alves1-7/+17
With GCC 6.4 and 6.5 (at least), unit tests that use gdbsupport/valid-expr.h's CHECK_VALID fail to compile, with: In file included from src/gdb/unittests/offset-type-selftests.c:24:0: src/gdb/unittests/offset-type-selftests.c: In substitution of 'template<class Expected, template<class ...> class Op, class ... Args> using is_detected_exact = std::is_same<Expected, typename gdb::detection_detail::detector<gdb::nonesuch, void, Op, Args ...>::type> [with Expected = selftests::offset_type::off_A&; Op = selftests::offset_type::check_valid_expr75::archetype; Args = {selftests::offset_type::off_A, selftests::offset_type::off_B}]': src/gdb/unittests/offset-type-selftests.c:75:1: required from here src/gdb/../gdbsupport/valid-expr.h:65:20: error: type/value mismatch at argument 2 in template parameter list for 'template<class Expected, template<class ...> class Op, class ... Args> using is_detected_exact = std::is_same<Expected, typename gdb::detection_detail::detector<gdb::nonesuch, void, Op, Args ...>::type>' archetype, TYPES>::value == VALID, \ ^ The important part is the "error: type/value mismatch" error. Seems like that GCC doesn't understand that archetype is an alias template, and is being strict in requiring a template class. The fix here is then to make archetype a template class, to pacify GCC. The resulting code looks like this: template <TYPENAMES, typename = decltype (EXPR)> struct archetype { }; static_assert (gdb::is_detected_exact<archetype<TYPES, EXPR_TYPE>, archetype, TYPES>::value == VALID, ""); is_detected_exact<Expected, Op, Args> checks whether Op<Args> is type Expected: - For Expected, we pass the explicit EXPR_TYPE, overriding the default parameter type of archetype. - For Args we don't pass the last template parameter, so archtype defaults to the EXPR's decltype. So in essence, we're really checking whether EXPR_TYPE is the same as decltype(EXPR). We need to do the decltype in a template context in order to trigger SFINAE instead of failing to compile. The hunk in unittests/enum-flags-selftests.c becomes necessary, because unlike with the current alias template version, this new version makes GCC trigger -Wenum-compare warnings as well: src/gdb/unittests/enum-flags-selftests.c:328:33: error: comparison between 'enum selftests::enum_flags_tests::RE' and 'enum selftests::enum_flags_tests::RE2' [-Werror=enum-compare] CHECK_VALID (true, bool, RE () != RE2 ()) ^ src/gdb/../gdbsupport/valid-expr.h:61:45: note: in definition of macro 'CHECK_VALID_EXPR_INT' template <TYPENAMES, typename = decltype (EXPR)> \ ^ Build-tested with: - GCC {4.8.5, 6.4, 6.5, 7.3.1, 9.3.0, 11.0.0-20200910} - Clang 10.0.0 gdbsupport/ChangeLog: * valid-expr.h (CHECK_VALID_EXPR_INT): Make archetype a template class instead of an alias template and adjust static_assert. gdb/ChangeLog: * unittests/enum-flags-selftests.c: Check whether __GNUC__ is defined before using '#pragma GCC diagnostic' instead of checking __clang__.
2020-09-14Rewrite enum_flags, add unit tests, fix problemsPedro Alves1-0/+586
This patch started by adding comprehensive unit tests for enum_flags. For the testing part, it adds: - tests of normal expected uses of the API. - checks that _invalid_ uses of the API would fail to compile. I.e., it validates that enum_flags really is a strong type, and that incorrect mixing of enum types would be caught at compile time. It pulls that off making use of SFINEA and C++11's decltype/constexpr. This revealed many holes in the enum_flags API. For example, the f1 assignment below currently incorrectly fails to compile: enum_flags<flags> f1 = FLAG1; enum_flags<flags> f2 = FLAG2 | f1; The unit tests also revealed that this useful use case doesn't work: enum flag { FLAG1 = 1, FLAG2 = 2 }; enum_flags<flag> src = FLAG1; enum_flags<flag> f1 = condition ? src : FLAG2; It fails to compile because enum_flags<flag> and flag are convertible to each other. Turns out that making enum_flags be implicitly convertible to the backing raw enum type was not a good idea. If we make it convertible to the underlying type instead, we fix that ternary operator use case, and, we find cases throughout the codebase that should be using the enum_flags but were using the raw backing enum instead. So it's a good change overall. Also, several operators were missing. These holes and more are plugged by this patch, by reworking how the enum_flags operators are implemented, and making use of C++11's feature of being able to delete methods/functions. There are cases in gdb/compile/ where we need to call a function in a C plugin API that expects the raw enum. To address cases like that, this adds a "raw()" method to enum_flags. This way we can keep using the safer enum_flags to construct the value, and then be explicit when we need to get at the raw enum. This makes most of the enum_flags operators constexpr. Beyond enabling more compiler optimizations and enabling the new unit tests, this has other advantages, like making it possible to use operator| with enum_flags values in switch cases, where only compile-time constants are allowed: enum_flags<flags> f = FLAG1 | FLAG2; switch (f) { case FLAG1 | FLAG2: break; } Currently that fails to compile. It also switches to a different mechanism of enabling the global operators. The current mechanism isn't namespace friendly, the new one is. It also switches to C++11-style SFINAE -- instead of wrapping the return type in a SFINAE-friently structure, we use an unnamed template parameter. I.e., this: template <typename enum_type, typename = is_enum_flags_enum_type_t<enum_type>> enum_type operator& (enum_type e1, enum_type e2) instead of: template <typename enum_type> typename enum_flags_type<enum_type>::type operator& (enum_type e1, enum_type e2) Note that the static_assert inside operator~() was converted to a couple overloads (signed vs unsigned), because static_assert is too late for SFINAE-based tests, which is important for the CHECK_VALID unit tests. Tested with gcc {4.8, 7.1, 9.3} and clang {5.0.2, 10.0.0}. gdb/ChangeLog: * Makefile.in (SELFTESTS_SRCS): Add unittests/enum-flags-selftests.c. * btrace.c (ftrace_update_caller, ftrace_fixup_calle): Use btrace_function_flags instead of enum btrace_function_flag. * compile/compile-c-types.c (convert_qualified): Use enum_flags::raw. * compile/compile-cplus-symbols.c (convert_one_symbol) (convert_symbol_bmsym): * compile/compile-cplus-types.c (compile_cplus_convert_method) (compile_cplus_convert_struct_or_union_methods) (compile_cplus_instance::convert_qualified_base): * go-exp.y (parse_string_or_char): Add cast to int. * unittests/enum-flags-selftests.c: New file. * record-btrace.c (btrace_thread_flag_to_str): Change parameter's type to btrace_thread_flags from btrace_thread_flag. (record_btrace_cancel_resume, record_btrace_step_thread): Change local's type to btrace_thread_flags from btrace_thread_flag. Add cast in DEBUG call. gdbsupport/ChangeLog: * enum-flags.h: Include "traits.h". (DEF_ENUM_FLAGS_TYPE): Declare a function instead of defining a structure. (enum_underlying_type): Update comment. (namespace enum_flags_detail): New. Move struct zero_type here. (EnumIsUnsigned, EnumIsSigned): New. (class enum_flags): Make most methods constexpr. (operator&=, operator|=, operator^=): Take an enum_flags instead of an enum_type. Make rvalue ref versions deleted. (operator enum_type()): Delete. (operator&, operator|, operator^, operator~): Delete, moved out of class. (raw()): New method. (is_enum_flags_enum_type_t): Declare. (ENUM_FLAGS_GEN_BINOP, ENUM_FLAGS_GEN_COMPOUND_ASSIGN) (ENUM_FLAGS_GEN_COMP): New. Use them to reimplement global operators. (operator~): Now constexpr and reimplemented. (operator<<, operator>>): New deleted functions. * valid-expr.h (CHECK_VALID_EXPR_5, CHECK_VALID_EXPR_6): New.