Great catch! If refactoring along those lines doesn’t clean up 100% of the cases then it’s worth explicitly breaking up groups of #include directives with comments. clang-format won’t reorder any non-contiguous groups and it’s a great way to explicitly call out dependencies.
Ideally we should be focused on committing changes along these lines so that there’s no post-format tweaking required to build cleanly again. Kate Stone k8st...@apple.com <mailto:k8st...@apple.com> Xcode Low Level Tools > On Aug 9, 2016, at 1:03 PM, Zachary Turner <ztur...@google.com> wrote: > > I ran clang-format and tried to build and got a bunch of compiler errors. > Most of them are order of include errors. I fixed everything in the attached > patch. I doubt this will apply cleanly for anyone unless you are at the > exact same revision as me, but at least you can look at it and get an idea of > what had to change. > > The #include win32.h thing is really annoying and hard for people to remember > the right incantation. I'm going to make a file called Host/PosixApi.h which > you can just include, no matter what platform you're on, and everything will > just work. That should clean up a lot of this nonsense. > > On Tue, Aug 9, 2016 at 11:10 AM Zachary Turner <ztur...@google.com > <mailto:ztur...@google.com>> wrote: > Another thing worth thinking about for the long term is library layering and > breaking the massive dependency cycle in LLDB. Every library currently > depends on every other library. This isn't good for build times, code size, > or reusability (especially where size matters like in lldb-server). I think > the massive Python dependency was removed after my work earlier this year. > But I'm not sure what the status of that is now, and there's still the rest > of LLDB. > > In the future it would be nice to have a modules build of LLDB. And sure, we > could just have liblldb be one giant module, but that seems to kind of defeat > the purpose of modules in the first place. > > For unit tests in particular, it's nice to be able to link in just the set of > things you need, and that's difficult / impossible right now. > > On Tue, Aug 9, 2016 at 10:00 AM Zachary Turner <ztur...@google.com > <mailto:ztur...@google.com>> wrote: > On Mon, Aug 8, 2016 at 2:40 PM Kate Stone via lldb-dev > <lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org>> wrote: > > Near-Term Goal: Standardizing on LLVM-style clang-format Rules > > We’ve heard from several in the community that would prefer to have a single > code formatting style to further unify the two code bases. Using > clang-format with the default LLVM conventions would simplify code migration, > editor configuration, and coding habits for developers who work in multiple > LLVM projects. There are non-trivial implications to reformatting a code > base with this much history. It can obfuscate history and impact downstream > projects by complicating merges. Ideally, it should be done once with as > much advance notice as is practical. Here’s the timeline we’re proposing: > > Today - mechanical reformatting proposed, comment period begins > > To get a preview of what straightforward reformatting of the code looks like, > just follow these steps to get a clean copy of the repository and reformat it: > Check out a clean copy of the existing repository > Edit .clang-format in the root of the tree, remove all but the line > “BasedOnStyle: LLVM” > Change your current working directory to the root of the tree to reformat > Double-check to make sure you did step 3 ;-) > Run the following shell command: "find . -name "*.[c,cpp,h] -exec > clang-format -i {} +" > > Aug 20th - comment period closes, final schedule proposed > TBD (early September?) - patches land in svn > > The purpose of the comment period is to review the straightforward diffs to > identify areas where comment pragmas should be used to avoid undesirable > formatting (tables laid out in code are a classic example.) It’s also a time > when feedback on the final timetable can be discussed, and any unforeseen > implications can be discovered. We understand that LLDB tends toward > relatively long names that may not always work well with the LLVM convention > of wrapping at 80 columns. Worst case scenarios will be evaluated to > determine the desired course of action. > > One thing we will need to take a look at is functions which have a very deep > indentation level. They have the potential to be made really ugly by > clang-format. The default indentation will be reduced from 4 to 2, so that > will help, but I recall we had some lines that began very far to the right. > > Here's a little bash command shows all lines with >= 50 leading spaces, > sorted in descending order by number of leading spaces. > > grep -n '^ \+' . -r -o | awk '{t=length($0);sub(" *$","");printf("%s%d\n", > $0, t-length($0));}' | sort -t: -n -k 3 -r | awk 'BEGIN { FS = ":" } ; { if > ($3 >= 50) print $0 }' > > It's less useful than I was hoping because most of the lines are noise (line > breaking in a function parameter list). > > If there were a way to detect indentation level that would be better. Mostly > just to identify places that we should manually inspect after running > clang-format. > <reformat.patch>
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
