This is an archive of the discontinued LLVM Phabricator instance.

[clang-format] Add a SpaceAroundPointerQualifiers style option
ClosedPublic

Authored by arichardson on Sep 24 2020, 6:48 AM.

Details

Summary

Some projects (e.g. FreeBSD) align pointers to the right but expect a
space between the '*' and any pointer qualifiers such as const. To handle
these cases this patch adds a new config option SpaceAroundPointerQualifiers
that can be used to configure whether spaces need to be added before/after
pointer qualifiers.

PointerAlignment = Right
SpaceAroundPointerQualifiers = Default/After:
void *const *x = NULL;
SpaceAroundPointerQualifiers = Before/Both
void * const *x = NULL;

PointerAlignment = Left
SpaceAroundPointerQualifiers = Default/Before:
void* const* x = NULL;
SpaceAroundPointerQualifiers = After/Both
void* const * x = NULL;

PointerAlignment = Middle
SpaceAroundPointerQualifiers = Default/Before/After/Both:
void * const * x = NULL;

Diff Detail

Event Timeline

arichardson created this revision.Sep 24 2020, 6:48 AM
Herald added a project: Restricted Project. · View Herald TranscriptSep 24 2020, 6:48 AM
arichardson requested review of this revision.Sep 24 2020, 6:48 AM
jrtc27 added inline comments.Sep 24 2020, 6:54 AM
clang/lib/Format/TokenAnnotator.cpp
2874–2889
arichardson added inline comments.Sep 24 2020, 7:01 AM
clang/lib/Format/TokenAnnotator.cpp
2874–2889

I feel like moving it here could in theory miss some cases. Also the condition is already barely comprehensible (I didn't attempt to understand which special cases all these conditions are for) and I don't feel like making it more complex.

If clang-format has identified that this */& token is a pointer/reference, and the next token is something that can be paresed as a pointer qualifier, shouldn't we trust the parser and simply look at the format option? It also IMO makes the code slightly easier to understand.

arichardson added inline comments.Sep 24 2020, 7:02 AM
clang/lib/Format/TokenAnnotator.cpp
2874–2889

Never mind, I thought your suggestion it was inside nested parens. It's equivalent just avoids the braces.

jrtc27 added inline comments.Sep 24 2020, 7:02 AM
clang/lib/Format/TokenAnnotator.cpp
2874–2889

It's a series of A || B || C || ..., and you just added an if (X) return true; above, so changing it to A || B || C || X || ... is entirely equivalent, no need to understand what any of the other expressions in the giant OR are.

2874–2889

Uh of course with || added on the end of that new sub-expression, managed to omit that...

arichardson marked 3 inline comments as done.

merge if with existing condition

MyDeveloperDay added inline comments.Sep 24 2020, 2:26 PM
clang/include/clang/Format/Format.h
2181

I wonder if a request would ever say they wanted this Space before to be Left/Middle/Right? perhaps this should not be a bool?

void* const *x;
void * const *x;
void *const *x;
void* const *x;
void * const *x;
void *const *x;
void* const * x;
void * const * x;
void *const * x;
void* const* x;
void * const* x;
void *const* x;
arichardson added inline comments.Sep 24 2020, 3:45 PM
clang/include/clang/Format/Format.h
2181

Shouldn't be too hard to implement so why not. How about PointerAlignmentForQualifiers as the setting name?

We will have to ensure that the default value matches PointerAlignment if it's not set since otherwise you'd get really weird code formatting after updating clang-format if you don't change the config file.
Are there and other settings that behave this way? If not I think I'd rather keep the boolean option.

Perhaps PointerAlignment should be an enum of Left, Middle, Right?
We maintain an internal patch that adds "ReferenceAlignment" as separate from PointerAlignment. So one could have:

PointerAlignment: Middle
ReferenceAlignment: Left

Use an enum config option instead

arichardson retitled this revision from [clang-format] Add a SpaceBeforePointerQualifiers style option to [clang-format] Add a SpaceAroundPointerQualifiers style option.Oct 7 2020, 8:27 AM
arichardson edited the summary of this revision. (Show Details)
This revision is now accepted and ready to land.Oct 14 2020, 12:07 PM
This revision was landed with ongoing or failed builds.Oct 18 2020, 10:47 AM
This revision was automatically updated to reflect the committed changes.