It's already checked in. It's not perfect yet, but it's close. The way I
run it against only changes in a CL involves having a chromium checkout on
my disk (yea, wtf, i know), and I don't know how to do it otherwise. Not
saying there's not a way, but I would ask over on cfe-dev or llvm-dev for
more info.
On Tue, Aug 19, 2014 at 11:14 AM, Sean Callanan <scalla...@apple.com> wrote:
> Please do forward that clang-format file when you have it put together. I
> would love to have access to that.
>
> Sean
>
> On Aug 19, 2014, at 11:06 AM, Zachary Turner <ztur...@google.com> wrote:
>
> Definitely agree with you on this. I have no plans to go fixup old code,
> and I don't think others should either. And if we see a change go through
> that does attempt to fix up old code, we should block it.
>
> That said, I'm working on a clang-format file that will automate this
> formatting for us (or at least, for me, should nobody else choose to use
> it), and I plan to run it against all my changelists before submitting
> them. Note that this only reformats lines that have already been touched
> by the CL, so there's no risk of formatting-only changes making it in.
>
>
> On Tue, Aug 19, 2014 at 11:00 AM, Sean Callanan <scalla...@apple.com>
> wrote:
>
>> One point about this discussion, by the way.
>>
>> While I support adherence to a consistent style for new/changed code,
>> this should in no way be taken as support for going through and fixing
>> indentation/style on old code.
>> We have internal branches that become hell to merge when e.g. spacing has
>> been altered subtly, or brace depth is changed…
>> If we all do our part to clean the parts we’re touching, then I think
>> that will be enough to keep LLDB clean.
>>
>> Sean
>>
>> On Aug 19, 2014, at 10:16 AM, Zachary Turner <ztur...@google.com> wrote:
>>
>> I brought this up in a thread on lldb-commits, but since it is of more
>> general interest, I want to make a thread here as well.
>>
>> Can we have clear direction on LLDB coding style? Ideally in the form of
>> an update to lldb.llvm.org, but as that might require a little more
>> effort, even some details in a response to this thread would be a help.
>> Some things I've deduced from looking at the code, and other things I'm
>> not so sure about, because of inconsistencies in the code or just no clear
>> rule.
>>
>> Indentation width: 4
>> Column limit: 140 (does this apply to comments too? Most
>> function-declaration comments seem to wrap at 80)
>> Brace style: Allman
>> if (foo)
>> {
>> // code here
>> }
>>
>> Break after function return type: Always, only on declarations, only on
>> definitions, only in headers, or never?
>>
>> Space before function parentheses: When?
>>
>> Indent case labels inside switch: A or B below?
>> switch (foo)
>> {
>> case A:
>> case B:
>> }
>>
>> Indent braces inside of a case: A or B below?
>> switch (foo)
>> {
>> case A:
>> {
>> }
>> case B:
>> {
>> }
>> }
>>
>> Any other rules I should be cognizant of?
>> _______________________________________________
>> lldb-dev mailing list
>> lldb-dev@cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>
>>
>>
>
>
_______________________________________________
lldb-dev mailing list
lldb-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
