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

Fri Dec 11 14:56:30 PST 2015

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20151211/a0808eef/attachment-0001.html>