From: Andrew Burgess <andrew.burgess@embecosm.com>
To: Pedro Alves <pedro@palves.net>
Cc: Tom Tromey <tom@tromey.com>, gdb-patches@sourceware.org
Subject: Re: [PATCH 1/8] gdbsupport: Provide global operators |=, &=, and ^= for enum bit flags
Date: Fri, 21 Aug 2020 16:57:42 +0100 [thread overview]
Message-ID: <20200821155742.GP853475@embecosm.com> (raw)
In-Reply-To: <89e07f2d-9c33-5f43-d62f-19571ac39c57@palves.net>
* Pedro Alves <pedro@palves.net> [2020-08-21 15:49:15 +0100]:
> On 8/17/20 11:40 AM, Andrew Burgess wrote:
>
> >
> > 3. Instead of writing 'enum some_flag', a developer might just write
> > 'some_flag'.
>
> I suspect you meant 'some_flags' in the latter case.
No, I meant 'some_flag'.
>
> > In this case they still require the changes from my
> > patch if they ever want to use operator|=. I think spotting the
> > missing 's' is much harder during review,
>
> I'd argue that that's an issue of naming. If people thing it's a
> problem, we can use a more distinct name for the raw enums.
> Some cases use enum foo_flag_value / foo_flags, which seems reasonable
> to me.
I don't understand where 'enum foo_flag_value' came from, so I can't
really respond to this.
>
> > so it's easy for uses of
> > 'some_flag' to creep into the code base, then a future developer
> > wanting to use 'operator|=' will need to fix up the 'some_flag' to
> > 'some_flags' miss-match. Though it's easy to argue that the first
> > developer made a mistake, and we frequently have to fix the mistakes
> > of those going before, in this case we don't have to, so why force
> > the matter?
> >
> > I guess my argument would be, lets commit. We should either remove
> > the existing global operators from enum-flags.h, fix up the fall out,
> > and so make it much harder to developers to use the 'some_flag'
> > version (so forcing the use of 'some_flags'), or make the change I
> > propose which allows the full range of operators while loosing non of
> > the protection that already exists.
>
> This (again) reminded me of my enum-flags.h rewrite that I never
> managed to commit...
>
> I spent time around it yesterday/today, and posted it here:
> https://sourceware.org/pipermail/gdb-patches/2020-August/171392.html
I saw this. Once this gets merged I'll rebase the rest of my series
on top of your work, at which point I assume that this patch will not
be required.
Thanks for your help,
Andrew
>
> Thanks,
> Pedro Alves
next prev parent reply other threads:[~2020-08-21 15:57 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-13 12:58 [PATCH 0/8] Fortran Array Slicing and Striding Support Andrew Burgess
2020-08-13 12:58 ` [PATCH 1/8] gdbsupport: Provide global operators |=, &=, and ^= for enum bit flags Andrew Burgess
2020-08-15 17:16 ` Tom Tromey
2020-08-16 9:13 ` Andrew Burgess
2020-08-17 10:40 ` Andrew Burgess
2020-08-20 16:00 ` Pedro Alves
2020-08-21 14:49 ` Pedro Alves
2020-08-21 15:57 ` Andrew Burgess [this message]
2020-08-21 18:10 ` Pedro Alves
2020-08-13 12:58 ` [PATCH 2/8] gdbsupport: Make function arguments constant in enum-flags.h Andrew Burgess
2020-08-15 19:45 ` Tom Tromey
2020-08-16 9:08 ` Andrew Burgess
2020-08-13 12:58 ` [PATCH 3/8] gdb/fortran: Clean up array/string expression evaluation Andrew Burgess
2020-08-13 12:58 ` [PATCH 4/8] gdb/fortran: Move Fortran expression handling into f-lang.c Andrew Burgess
2020-08-13 12:58 ` [PATCH 5/8] gdb/fortran: Change whitespace when printing arrays Andrew Burgess
2020-08-13 12:58 ` [PATCH 6/8] gdb: Convert enum range_type to a bit field enum Andrew Burgess
2020-08-13 12:58 ` [PATCH 7/8] gdb/testsuite: Add missing expected results Andrew Burgess
2020-08-13 12:58 ` [PATCH 8/8] gdb/fortran: Add support for Fortran array slices at the GDB prompt Andrew Burgess
2020-08-13 13:31 ` Eli Zaretskii
2020-08-26 14:49 ` [PATCHv2 00/10] Fortran Array Slicing and Striding Support Andrew Burgess
2020-08-26 14:49 ` [PATCHv2 01/10] Rewrite valid-expr.h's internals in terms of the detection idiom (C++17/N4502) Andrew Burgess
2020-08-26 14:49 ` [PATCHv2 02/10] Use type_instance_flags more throughout Andrew Burgess
2020-08-26 14:49 ` [PATCHv2 03/10] Rewrite enum_flags, add unit tests, fix problems Andrew Burgess
2020-08-26 14:49 ` [PATCHv2 04/10] gdb: additional changes to make use of type_instance_flags more Andrew Burgess
2020-08-26 14:49 ` [PATCHv2 05/10] gdb/fortran: Clean up array/string expression evaluation Andrew Burgess
2020-09-19 8:53 ` Andrew Burgess
2020-08-26 14:49 ` [PATCHv2 06/10] gdb/fortran: Move Fortran expression handling into f-lang.c Andrew Burgess
2020-09-19 8:53 ` Andrew Burgess
2020-08-26 14:49 ` [PATCHv2 07/10] gdb/fortran: Change whitespace when printing arrays Andrew Burgess
2020-09-19 8:54 ` Andrew Burgess
2020-08-26 14:49 ` [PATCHv2 08/10] gdb: Convert enum range_type to a bit field enum Andrew Burgess
2020-08-26 14:49 ` [PATCHv2 09/10] gdb/testsuite: Add missing expected results Andrew Burgess
2020-09-18 9:53 ` Andrew Burgess
2020-08-26 14:49 ` [PATCHv2 10/10] gdb/fortran: Add support for Fortran array slices at the GDB prompt Andrew Burgess
2020-08-26 17:02 ` Eli Zaretskii
2020-09-19 9:47 ` [PATCHv3 0/2] Fortran Array Slicing and Striding Support Andrew Burgess
2020-09-19 9:48 ` [PATCHv3 1/2] gdb: Convert enum range_type to a bit field enum Andrew Burgess
2020-09-19 13:50 ` Simon Marchi
2020-09-19 9:48 ` [PATCHv3 2/2] gdb/fortran: Add support for Fortran array slices at the GDB prompt Andrew Burgess
2020-09-19 10:03 ` Eli Zaretskii
2020-09-28 9:40 ` [PATCHv4 0/3] Fortran Array Slicing and Striding Support Andrew Burgess
2020-09-28 9:40 ` [PATCHv4 1/3] gdb: Convert enum range_type to a bit field enum Andrew Burgess
2020-09-28 9:40 ` [PATCHv4 2/3] gdb: rename 'enum range_type' to 'enum range_flag' Andrew Burgess
2020-09-28 9:40 ` [PATCHv4 3/3] gdb/fortran: Add support for Fortran array slices at the GDB prompt Andrew Burgess
2020-09-28 9:52 ` Eli Zaretskii
2020-10-11 18:12 ` [PATCHv5 0/4] Fortran Array Slicing and Striding Support Andrew Burgess
2020-10-11 18:12 ` [PATCHv5 1/4] gdb: Convert enum range_type to a bit field enum Andrew Burgess
2020-10-20 20:16 ` Tom Tromey
2020-10-11 18:12 ` [PATCHv5 2/4] gdb: rename 'enum range_type' to 'enum range_flag' Andrew Burgess
2020-10-20 20:16 ` Tom Tromey
2020-10-11 18:12 ` [PATCHv5 3/4] gdb/fortran: add support for parsing array strides in expressions Andrew Burgess
2020-10-12 13:21 ` Simon Marchi
2020-10-20 20:17 ` Tom Tromey
2020-10-22 10:42 ` Andrew Burgess
2020-10-11 18:12 ` [PATCHv5 4/4] gdb/fortran: Add support for Fortran array slices at the GDB prompt Andrew Burgess
2020-10-12 14:10 ` Simon Marchi
2020-10-20 20:45 ` Tom Tromey
2020-10-29 11:08 ` Andrew Burgess
2020-10-31 22:16 ` [PATCHv6] " Andrew Burgess
2020-11-12 12:09 ` Andrew Burgess
2020-11-12 18:58 ` Tom Tromey
2020-11-19 11:56 ` Andrew Burgess
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200821155742.GP853475@embecosm.com \
--to=andrew.burgess@embecosm.com \
--cc=gdb-patches@sourceware.org \
--cc=pedro@palves.net \
--cc=tom@tromey.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).