[lldb-dev] clang-format now supports return type on separate line

Todd Fiala via lldb-dev lldb-dev at lists.llvm.org
Thu Jan 21 21:46:19 PST 2016


Okay, sounds like a reasonable thing to try.  We can always review it if it
causes any real issues.

On Thu, Jan 21, 2016 at 11:34 AM, Zachary Turner <zturner at google.com> wrote:

>
>
> On Thu, Jan 21, 2016 at 11:18 AM Sean Callanan <scallanan at apple.com>
> wrote:
>
>> I tend to agree with Zachary on the overall principle – and I would be
>> willing to clang-format functions when I modify them.  I’m concerned about
>> a specific class of functions, though.  Let’s say I have a function that
>> has had lots of activity (I’m thinking of, for example, ParseType off in
>> the DWARF parser).  Unfortunately, such functions tend to be the ones that
>> benefit most from clang-format.
>>
>> In such a function, there’s a lot of useful history available via svn
>> blame that helps when fixing bugs.  My concern is that if someone
>> clang-formats this function after applying the *k*th fix, suddenly I've
>> lost convenient access to that history.  It’s only available with a fair
>> amount of pain, and this pain increases as more fixes are applied because
>> now I need to interleave the info before and after reformatting.
>>
>> Would it be reasonable to mark such functions as “Don’t clang-format”?
>> That could be also interpreted as a “// TODO add comments so what this does
>> is more understandable”
>>
>
> Well again by default it's only going to format the code you touch in yoru
> diff plus 1 or 2 surrounding lines.  So having it format an entire function
> is something you would have to explicitly go out of your way to do.  So
> it's a judgement call.  If you think the function would be better off
> clang-formatting the entire thing, do that.  If you just want to format the
> lines you're touching because you were in there anyway, that's the default
> behavior.
>



-- 
-Todd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20160121/9466303a/attachment.html>


More information about the lldb-dev mailing list