This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH v3] Align natural-format register values to the same column
On 2018-02-03 06:43 AM, Ruslan Kabatsayev wrote:
> I'm extremely sorry for making you repeat your comments. I keep
> missing some formatting bits. Are there any known-working options for
> any linter/indenter so that I could automatically check/prettify my
> GDB patches before posting? I've tried astyle, but it somehow messes
> up spaces/tabs and doesn't seem to support half-indenting enum braces
> (or I didn't use the correct options). GNU indent appears to confuse
> C++ references with bitwise OR, putting spaces on both sides, and also
> doesn't want to half-indent enums.
I don't know of any tool/config that does it right out of the box, but if
you manage to find a solution that works nicely, please share it. The problem
is often that if you run files through an automatic formatter, you'll have a huge
diff of little changes (fix existing style issues, change how things are wrapped,
etc). If there was a way to tell the formatter to only touch the lines that were
touched in your patch, it would be ideal.
What do you mean by half-indent enum, do you mean that the curly braces are
indented with respect to the enum keywork, like this?
enum tab_stops
{
value_column_1 = 15,
/* Give enough room for "0x", 16 hex digits and two spaces in
preceding column. */
value_column_2 = value_column_1 + 2 + 16 + 2,
};
I've seen inconsistent style in GDB between the above, and this:
enum tab_stops
{
value_column_1 = 15,
/* Give enough room for "0x", 16 hex digits and two spaces in
preceding column. */
value_column_2 = value_column_1 + 2 + 16 + 2,
};
I think the second version makes more sense, because it mimics how it's
done for functions. But I don't know if it should be different if the
enum is declared inside the scope of a function. If your formatter
writes it like the second version, I would be totally fine with it.
> I've sent a new version of the patch.
Thanks, I'll look at it later.
Simon