[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