Er, I was twisting them together. I've been meaning clang-format. On Fri, Dec 11, 2015 at 2:56 PM, Zachary Turner <ztur...@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.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 >> > -- -Todd
_______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
