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.fi...@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 <ztur...@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 <ztur...@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.fi...@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 <ztur...@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.fi...@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 <ztur...@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.zele...@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 <ztur...@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.fi...@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 <jing...@apple.com> >>>>>>>> wrote: >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> >>> On Dec 11, 2015, at 2:01 PM, Todd Fiala via lldb-commits >>>>>>>> >>> <lldb-commits@lists.llvm.org> wrote: >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> >>> On Fri, Dec 11, 2015 at 1:59 PM, Zachary Turner < >>>>>>>> ztur...@google.com> >>>>>>>> >>> wrote: >>>>>>>> >>>> >>>>>>>> >>>> On Fri, Dec 11, 2015 at 1:55 PM Todd Fiala via lldb-commits >>>>>>>> >>>> <lldb-commits@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@lists.llvm.org >>>>>>>> >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> -- >>>>>>>> >> -Todd >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> -Todd >>>>>> >>>>> >>>> >>>> >>>> -- >>>> -Todd >>>> >>> > > > -- > -Todd >
_______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
