[cfe-dev] Extending clang-format

Andrew Hankins via cfe-dev cfe-dev at lists.llvm.org
Mon Nov 2 16:29:55 PST 2015


Hi Daniel,

Thanks for the response. I understand the clang maintainer's perspective on
this issue but I'd still like to attempt to support my formatting styles.
If clang devs decide its not the direction they'd like to take that's cool
but its probably still worth my time to make the modifications to support
it - it will save me lots of time :)

So if you have any pointers or where to embark on this I'd appreciate it
otherwise I'll continue to wade/experiment my way through.

If I get to a place where its working and its not a dog's breakfast I'll
give you guys a look and you can make your own mind up, no hard feelings.

Thanks,
Andrew



On Sat, Oct 31, 2015 at 3:12 PM, Daniel Jasper <djasper at google.com> wrote:

> First off, please read:
>
> http://clang.llvm.org/docs/ClangFormatStyleOptions.html#adding-additional-style-options
>
> My initial thoughts on the two requested changes:
>
> Namespaces: This isn't worth adding the complexity for. Yes, it wastes a
> bit of vertical space, but it is also in a place in the file where vertical
> space really doesn't matter this much. Plus, with C++17, this is going to
> become a non-issue as you can just declare "namespace a::b::c {". I feel
> like there has been an argument about this before.
>
> Function parameters: This goes against some quite fundamental assumptions,
> that clang-format is making. While it certainly can be done, I'd be
> hesitant to get this in unless there is strong evidence that the
> requirements presented in the link are fulfilled.
>
> Sorry, I actually hate being so negative. However, I also want
> clang-format to remain maintainable and provide the best possible
> experience for most people.
>
> Cheers,
> Daniel
>
>
> On Fri, Oct 30, 2015 at 6:23 PM, Andrew Hankins via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
>> Hi all,
>>
>> First post.
>>
>> I've found clang-format to be a very powerful and useful tool and I'd
>> like to start extending it to support some other formatting styles that I
>> have to work with. The two changes I'd like to start with are to namespaces
>> and function parameters.
>> For namespaces I'd like create a configuration parameter that would allow
>> nested namespaces all on one line.
>>
>> Rather than
>>
>> namespace a {
>> namespace b {
>> namespace c{
>> }
>> }
>> };
>>
>> Support
>>
>> namespace a { namespace b { namespace c {
>> }}};
>>
>> and for functions rather than
>>
>> int foo(int param1,
>>           int param2)
>> {
>> }
>>
>> Support
>>
>> int foo
>> (
>>     int param1,
>>     int pararm2
>> )
>> {
>> }
>>
>>
>> I've started to poke around in the clang lib/Format code but I'm finding
>> it difficult to figure out where the best place to make the changes is and
>> there isn't much documentation on the clang-format design/code I can find.
>> I think the rough idea in clang-format is to use the UnwrappedLineParser
>> to separate the code into the appropriate lines, then using the
>> UnwrappedLineFormatter annotate the tokens, merge lines where possible and
>> delete unnecessary lines then finally dump it all.
>>
>> Taking my namespace change for example I've made modifications to the
>> UnwrappedLineParser::parseBlock so it won't always add a newline from
>> parseNamespace
>>
>> -----------------------------------------------------
>> @@ -399,7 +399,7 @@ void UnwrappedLineParser::calculateBraceTypes(bool
>> ExpectClassBody) {
>>  }
>>
>>  void UnwrappedLineParser::parseBlock(bool MustBeDeclaration, bool
>> AddLevel,
>> -                                     bool MunchSemi) {
>> +                                     bool MunchSemi, bool AddLine) {
>>    assert(FormatTok->isOneOf(tok::l_brace, TT_MacroBlockBegin) &&
>>           "'{' or macro block token expected");
>>    const bool MacroBlock = FormatTok->is(TT_MacroBlockBegin);
>> @@ -410,7 +410,7 @@ void UnwrappedLineParser::parseBlock(bool
>> MustBeDeclaration, bool AddLevel,
>>    if (MacroBlock && FormatTok->is(tok::l_paren))
>>      parseParens();
>>
>> -  addUnwrappedLine();
>> +  if (AddLine) addUnwrappedLine();
>>
>>    ScopedDeclarationState DeclarationState(*Line, DeclarationScopeStack,
>>                                            MustBeDeclaration);
>> ---------------------------------
>>
>> and this works somewhat but the namespaces are now missing whitespaces
>> and you get
>>
>> namespace a{namespace b{namespace c{
>> }
>> }
>> }
>>
>> So instead should I write a line merger for namespaces? Or should I find
>> a way to update the insert whitespace before/after flag?
>>
>> I guess I'm just looking for some guidance on how to best approach this
>> kind of work or to be pointed in the direction of more doco.
>>
>> Thanks in advance,
>>
>> Andrew
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20151103/2d3216e1/attachment.html>


More information about the cfe-dev mailing list