[lldb-dev] LLDB Evolution

[Zachary Turner via lldb-dev]

Standardizing include order would really help.  LLVM's style is documented
here <http://llvm.org/docs/CodingStandards.html#include-style>, but to
quote it:


   1. Main Module Header
   2. Local/Private Headers
   3. llvm/...
   4. System #includes

So perhaps it would be reasonable for us to standardize on something like
this:


   1. Main Module Header
   2. Local/Private Headers
   3. lldb/...
   4. llvm/...
   5. System #includes

Putting LLDB headers before LLVM headers is a nice way to enforce "include
what you use".  Otherwise you might have something like this:

// lldb.cpp
#include "llvm/LLVM1.h"
#include "lldb/lldb2.h

// lldb2.h
llvm::MyType foo();

And this will work, even though lldb2.h needs to have #include
"llvm/LLVM1.h"

So the above ordering fixes that.  clang-format won't solve this for us
automatically, but it would be nice to at least move towards it.

On Tue, Aug 9, 2016 at 2:49 PM Kate Stone <k8stone at apple.com> wrote:

> 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 k8stone at apple.com
>  Xcode Low Level Tools
>
> On Aug 9, 2016, at 1:03 PM, Zachary Turner <zturner at 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 <zturner at 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 <zturner at google.com>
>> wrote:
>>
>>> On Mon, Aug 8, 2016 at 2:40 PM Kate Stone via lldb-dev <
>>> lldb-dev at 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:
>>>>
>>>>
>>>>    1. Check out a clean copy of the existing repository
>>>>    2. Edit .clang-format in the root of the tree, remove all but the
>>>>    line “BasedOnStyle: LLVM”
>>>>    3. Change your current working directory to the root of the tree to
>>>>    reformat
>>>>    4. Double-check to make sure you did step 3 ;-)
>>>>    5. 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>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20160809/f84503d9/attachment.html>