Jim, I think you and I have talked about this in the past. Care to comment?
On Thu, Jan 21, 2016 at 11:18 AM, Sean Callanan <scalla...@apple.com> wrote: > I tend to agree with Zachary on the overall principle – and I would be > willing to clang-format functions when I modify them. I’m concerned about > a specific class of functions, though. Let’s say I have a function that > has had lots of activity (I’m thinking of, for example, ParseType off in > the DWARF parser). Unfortunately, such functions tend to be the ones that > benefit most from clang-format. > > In such a function, there’s a lot of useful history available via svn > blame that helps when fixing bugs. My concern is that if someone > clang-formats this function after applying the *k*th fix, suddenly I've > lost convenient access to that history. It’s only available with a fair > amount of pain, and this pain increases as more fixes are applied because > now I need to interleave the info before and after reformatting. > > Would it be reasonable to mark such functions as “Don’t clang-format”? > That could be also interpreted as a “// TODO add comments so what this does > is more understandable” > > Sean > > On Jan 21, 2016, at 10:59 AM, Zachary Turner via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > Also this is the same standard that applies to the rest of LLVM. > clang-format your patches. Just because we haven't been consistently > following the rules until now doesn't mean we should continue to not follow > the rules going forward. This way eventually the codebase slowly converges > towards a properly formatted one. If clang-format does something that you > think looks awkward with respect to the surrounding code (perhaps within a > single logical block or whatever else) then just touch a line of code in > the surrounding area so that clang-format will do it too. Since it only > formats the differential, you have as much control as you need to produce > something that a) is consistent with the rules, and b) doesn't look awkward > with respect to surrounding code. > > On Thu, Jan 21, 2016 at 10:11 AM Zachary Turner <ztur...@google.com> > wrote: > >> I'm not sure I agree. I don't think anything will be awkwardly formatted >> with regards to the rest of the file. The biggest thing this is going to >> fix are whitespace at the end of lines, line breakign conventions, and >> space between function name and parentheses. >> >> If we're not going to enforce a coding style, why have one at all? >> clang-format enforces it. >> >> On Thu, Jan 21, 2016 at 8:41 AM Todd Fiala <todd.fi...@gmail.com> wrote: >> >>> Glad to see clang-format getting some improvements. >>> >>> >>> >>> On Thu, Jan 7, 2016 at 10:30 AM, Zachary Turner <ztur...@google.com> >>> wrote: >>> >>>> As far as I'm aware, this is the last major incompatibility between >>>> LLDB's style and clang-format's feature set. >>>> >>>> I would appreciate it if more people could try it out with a few of >>>> their patches, and let me know if any LLDB style incompatibilities arise in >>>> the formatted code. >>>> >>>> I would eventually like to move towards requiring that all patches be >>>> clang-formatted before committing to LLDB. >>>> >>> >>> Question to the group on that last part. I think if we have a large >>> body of code that is just getting a few tweaks to a method, having the >>> patch run through the formatter could lead to some pretty ugly code. >>> Imagine a few lines of a file awkwardly formatted related to the rest of >>> the file. Since we're not trying to reformat everything at once (which >>> makes for difficult code traceability), and given there was a large code >>> base to start with before LLDB was part of LLVM, I'm not sure we want a >>> blanket statement that says it must go through clang-format. (I personally >>> would be fine with doing whole new functions and other logical blocks of >>> code via clang-format when inserted into existing code, but I think it >>> probably extreme when we're talking about new little sections within >>> existing functions). >>> >>> Thoughts? >>> >>> >>> >>> -- >>> -Todd >>> >> _______________________________________________ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > > -- -Todd
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
