[Lldb-commits] [lldb] r255364 - Fix Clang-tidy modernize-use-nullptr and readability-simplify-boolean-expr warnings in source/Target/Target.cpp.

Fri Dec 11 15:03:05 PST 2015

Er, I was twisting them together.  I've been meaning clang-format.

On Fri, Dec 11, 2015 at 2:56 PM, Zachary Turner <zturner at google.com> wrote:

> Well clang-tidy doesn't help with the coding standard anyway.  It's more
> semantic style rather than syntax style.  nullptr instead of NULL, Foo() =
> delete instead of making a constructor private.  That type of thing.
>
> I'm happy letting clang-tidy be postprocessing steps that peopel
> occasionally run over the code, as I think clang-format has a lot more
> value, at least in the short term.
>
> On Fri, Dec 11, 2015 at 2:53 PM Todd Fiala <todd.fiala at gmail.com> wrote:
>
>> What if we embedded a version?  Made whatever modifications we needed,
>> and just merged occasionally from the source?  That would lower the
>> barrier, at the cost of raising the need to refresh occasionally.  But then
>> you could count on it being there.
>>
>> Seems like a lot of work, though.  A simple alternative is to learn the
>> coding standard.
>>
>> On Fri, Dec 11, 2015 at 2:49 PM, Zachary Turner <zturner at google.com>
>> wrote:
>>
>>> clang-tidy is a little more problematic, because the source for
>>> clang-tidy isn't even in the same repository.  You literally have to clone
>>> an entirely separate repo to get it, so it's not built by default.  This
>>> kind of raises the barrier to entry for using clang-tidy IMO, which is
>>> unfortunate since it's a pretty nice tool.
>>>
>>> On Fri, Dec 11, 2015 at 2:46 PM Zachary Turner <zturner at google.com>
>>> wrote:
>>>
>>>> No I'm not talking about whitespace at the end of a line, I'm saying
>>>> LLVM's style (and what clang-format does) is this:
>>>>
>>>> Foo::Foo()
>>>>    : member_1()
>>>>    , member_2()
>>>>    , member_3()
>>>>
>>>> and what LLDB wants is this:
>>>>
>>>> Foo::Foo() :
>>>>     member1(),
>>>>     member2(),
>>>>     member3()
>>>>
>>>> Neither one have whitespace at the end of a line.
>>>>
>>>> On Fri, Dec 11, 2015 at 2:44 PM Todd Fiala <todd.fiala at gmail.com>
>>>> wrote:
>>>>
>>>>> Okay.  Ending a line with arbitrary whitespace seems wrong as just
>>>>> about any colorizing editor or diff will flag, but I'll survive :-)
>>>>>
>>>>> On Fri, Dec 11, 2015 at 2:42 PM, Zachary Turner <zturner at google.com>
>>>>> wrote:
>>>>>
>>>>>> Yes, but as I mentioned, two things are still unsupported due to
>>>>>> limitations in clang-format.  They are return-type-on-new-line (only in
>>>>>> declarations.  clang-format supports it for definitions) and the
>>>>>> constructor initializer list comma at the end (clang-format puts it at the
>>>>>> beginning).
>>>>>>
>>>>>> That said, the comma at the end of initializer list isn't documented
>>>>>> on that page, and where we don't have a clearly documented rule, prefer the
>>>>>> LLVM guidelines, so....
>>>>>>
>>>>>>
>>>>>> On Fri, Dec 11, 2015 at 2:37 PM Todd Fiala <todd.fiala at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Okay, but does the format match the LLDB-modified format with some
>>>>>>> kind of configuration file?  We still need to match our guidelines here:
>>>>>>>
>>>>>>> http://lldb.llvm.org/lldb-coding-conventions.html
>>>>>>>
>>>>>>> We can achieve that with a config file for it, right?  (Maybe
>>>>>>> already existing, maybe in the lldb source tree already?)
>>>>>>>
>>>>>>> On Fri, Dec 11, 2015 at 2:35 PM, Zachary Turner <zturner at google.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> With git you can already run "git clang-format".  You just need
>>>>>>>> `git-clang-format` to be in your PATH (it's under llvm/tools/clang).  Not
>>>>>>>> sure how to hook it into SVN
>>>>>>>>
>>>>>>>> On Fri, Dec 11, 2015 at 2:32 PM Eugene Zelenko <
>>>>>>>> eugene.zelenko at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> At least clang-format should be applied to all newly added files
>>>>>>>>> before commit.
>>>>>>>>>
>>>>>>>>> Eugene.
>>>>>>>>>
>>>>>>>>> On Fri, Dec 11, 2015 at 2:30 PM, Zachary Turner <
>>>>>>>>> zturner at google.com> wrote:
>>>>>>>>> > Back on the topic of clang-format, what would it take to make
>>>>>>>>> clang-format a
>>>>>>>>> > regular part of peoples' workflows?
>>>>>>>>> >
>>>>>>>>> > On Fri, Dec 11, 2015 at 2:27 PM Todd Fiala <todd.fiala at gmail.com>
>>>>>>>>> wrote:
>>>>>>>>> >>
>>>>>>>>> >> Yep - sorry.  I had been talking to Greg about this and
>>>>>>>>> misunderstood his
>>>>>>>>> >> comment on it. My mistake entirely.  Kate and I just talked and
>>>>>>>>> she pointed
>>>>>>>>> >> me to your document, Jim.
>>>>>>>>> >>
>>>>>>>>> >> The description was:
>>>>>>>>> >> where we had a clearly adhered to standard, keep it.
>>>>>>>>> >> whee we didn't, we adopted LLVM.
>>>>>>>>> >>
>>>>>>>>> >> Sorry for rehashing!
>>>>>>>>> >>
>>>>>>>>> >> -Todd
>>>>>>>>> >>
>>>>>>>>> >> On Fri, Dec 11, 2015 at 2:12 PM, Jim Ingham <jingham at apple.com>
>>>>>>>>> wrote:
>>>>>>>>> >>>
>>>>>>>>> >>>
>>>>>>>>> >>> On Dec 11, 2015, at 2:01 PM, Todd Fiala via lldb-commits
>>>>>>>>> >>> <lldb-commits at lists.llvm.org> wrote:
>>>>>>>>> >>>
>>>>>>>>> >>>
>>>>>>>>> >>>
>>>>>>>>> >>> On Fri, Dec 11, 2015 at 1:59 PM, Zachary Turner <
>>>>>>>>> zturner at google.com>
>>>>>>>>> >>> wrote:
>>>>>>>>> >>>>
>>>>>>>>> >>>> On Fri, Dec 11, 2015 at 1:55 PM Todd Fiala via lldb-commits
>>>>>>>>> >>>> <lldb-commits at lists.llvm.org> wrote:
>>>>>>>>> >>>>>
>>>>>>>>> >>>>> Hey Eugene and Greg,
>>>>>>>>> >>>>>
>>>>>>>>> >>>>> I thought we were doing spaces before the open parens in
>>>>>>>>> places like
>>>>>>>>> >>>>> this:
>>>>>>>>> >>>>>
>>>>>>>>> >>>>> -    BreakpointResolverSP resolver_sp(new
>>>>>>>>> BreakpointResolverFileLine
>>>>>>>>> >>>>> (NULL,
>>>>>>>>> >>>>> ...
>>>>>>>>> >>>>> +    BreakpointResolverSP resolver_sp(new
>>>>>>>>> >>>>> BreakpointResolverFileLine(nullptr,
>>>>>>>>> >>>>>
>>>>>>>>> >>>>> (see the removal of the space after
>>>>>>>>> BreakpointResolverFileLine from the
>>>>>>>>> >>>>> clang-tidy settings I presume).
>>>>>>>>> >>>>>
>>>>>>>>> >>>>> Did I misunderstand that?
>>>>>>>>> >>>>
>>>>>>>>> >>>>
>>>>>>>>> >>>> This was officially removed from the coding standard some
>>>>>>>>> months ago,
>>>>>>>>> >>>
>>>>>>>>> >>>
>>>>>>>>> >>> Okay.  Are we 100% in sync with LLVM coding standard
>>>>>>>>> guidelines?  If so I
>>>>>>>>> >>> can just look there to see what we're supposed to be doing.
>>>>>>>>> >>>
>>>>>>>>> >>>
>>>>>>>>> >>> No, the differences between the lldb and llvm coding standards
>>>>>>>>> are
>>>>>>>>> >>> documented in:
>>>>>>>>> >>>
>>>>>>>>> >>> http://lldb.llvm.org/lldb-coding-conventions.html
>>>>>>>>> >>>
>>>>>>>>> >>> Jim
>>>>>>>>> >>>
>>>>>>>>> >>>
>>>>>>>>> >>>>
>>>>>>>>> >>>> but not everyone has adopted this unfortunately.  See
>>>>>>>>> r228860.  It pains
>>>>>>>>> >>>> me to no end that we differ from LLVM, because it leads to
>>>>>>>>> exactly these
>>>>>>>>> >>>> type of problems where people aren't sure what the exact set
>>>>>>>>> of rules are.
>>>>>>>>> >>>
>>>>>>>>> >>>
>>>>>>>>> >>>
>>>>>>>>> >>>
>>>>>>>>> >>> --
>>>>>>>>> >>> -Todd
>>>>>>>>> >>> _______________________________________________
>>>>>>>>> >>> lldb-commits mailing list
>>>>>>>>> >>> lldb-commits at lists.llvm.org
>>>>>>>>> >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>>>>>>>>> >>>
>>>>>>>>> >>>
>>>>>>>>> >>
>>>>>>>>> >>
>>>>>>>>> >>
>>>>>>>>> >> --
>>>>>>>>> >> -Todd
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> -Todd
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> -Todd
>>>>>
>>>>
>>
>>
>> --
>> -Todd
>>
>

-- 
-Todd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20151211/0b74379f/attachment.html>