<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Following up from yesterday, everything now builds and runs cleanly with the configuration described below on macOS. I did have to make one set of minor changes to preserve #include ordering, but that’s already committed to trunk so there are no true blockers at this point. To keep pushing forward I’d like to propose the following final schedule for comment:<div class=""><br class=""></div><div class=""><b class="">Today-Sept 4th</b><span class="Apple-tab-span" style="white-space: pre;"> </span>Any final changes to prevent automatic formatting (see existing uses of <font face="Menlo" class="">// clang-format off</font> and <font face="Menlo" class="">// clang-format on</font> in source for reference.</div><div class=""><b class="">Sept 5th</b><span class="Apple-tab-span" style="white-space: pre;"> </span>Trunk closes for commits while reformatting takes place and is validated before re-opening trunk.<br class=""><div class=""><br class=""></div><div class="">Following the reformatting trying to merge the resulting diff will be a nightmare for anyone with their own long-lived branch or fork of the project. We’ll include a commit message describing the situation, but the sanest move is almost certainly to merge all diffs up to the formatting exercise and then simply format your own branch independently in lieu of actually attempting the merge. We will ensure that nothing takes place in that commit aside from the automated formatting.</div><div class=""><br class=""></div><div class="">We’ll be following the same strategy with the swift-lldb repository on GitHub.</div><div class=""><br class=""></div><div class="">Any concerns?</div><div class=""><br class=""><div class="">
<div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="" style="font-family: LucidaGrande; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><font color="#424242" class="" style="font-family: 'Lucida Grande'; font-size: x-small;">Kate Stone</font><span class="" style="font-family: 'Lucida Grande'; font-size: x-small;"> </span><font color="#009193" class="" style="font-family: 'Lucida Grande'; font-size: x-small;"><a href="mailto:k8stone@apple.com" class="">k8stone@apple.com</a></font></div><div class="" style="font-family: Times; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><font face="Lucida Grande" size="1" class=""><font color="#009193" class=""></font> Xcode <font color="#424242" class="">Low Level Tools</font></font></div></div></div></div></div></div>
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">On Aug 18, 2016, at 11:15 AM, Kate Stone via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org" class="">lldb-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">If there’s consensus on a reasonable automated formatting solution for Python then I’m fine with going ahead and doing so at the same time. The PEP-8 standard would leave Python code with 4-space indentation, and impart a consistent look to our code. Earlier this week I verified that our current repository builds and passes tests cleanly under the following conditions:<div class=""><br class=""></div><div class=""><ul class="MailOutline"><li class="">LLVM-style default .clang-format specified at the root of the tree:</li></ul><div class=""><br class=""></div><div class=""><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; background-color: rgb(255, 255, 255);" class=""><span style="font-variant-ligatures: no-common-ligatures" class="">BasedOnStyle: LLVM</span></div></div><div class=""><span style="font-variant-ligatures: no-common-ligatures" class=""><br class=""></span></div><ul class="MailOutline"><li class="">Formatting disabled using .clang-format in <span style="font-family: Menlo; font-size: 11px; background-color: rgb(255, 255, 255);" class="">packages/Python/lldbsuite</span>. It’s not just a matter of comment style and location driving tests. The tests themselves are exercising debugging functionality driven by debug information line tables. Debugging behavior can and will change when using line-oriented requests (breakpoint on a particular line, step over a particular line, etc.):</li></ul><div class=""><br class=""></div><div class=""><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; background-color: rgb(255, 255, 255);" class=""><span style="font-variant-ligatures: no-common-ligatures" class="">DisableFormat: true</span></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; background-color: rgb(255, 255, 255); min-height: 13px;" class=""><span style="font-variant-ligatures: no-common-ligatures" class=""></span><br class=""></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; background-color: rgb(255, 255, 255);" class=""><span style="font-variant-ligatures: no-common-ligatures" class=""># Disabling formatting doesn't implicitly disable include sorting</span></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; background-color: rgb(255, 255, 255);" class=""><span style="font-variant-ligatures: no-common-ligatures" class="">SortIncludes: false</span></div></div><div class=""><span style="font-variant-ligatures: no-common-ligatures" class=""><br class=""></span></div><ul class="MailOutline"><li class="">Formatting automatically applied for all .c, .h, and .cpp sources in the tree</li></ul><div class=""><br class=""></div><div class="">I’ll run the full suite again following reformatting using <a href="https://pypi.python.org/pypi/autopep8" class="">autopep8</a> for all .py files.</div><div class=""><br class=""></div><div class="">Thanks to everyone who has chimed in with suggestions, and with contributions to ensure that include ordering doesn’t become an issue on other platforms.</div><div class=""><br class=""></div><div class="">
<div style="letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="" style="font-family: LucidaGrande; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><font color="#424242" class="" style="font-family: 'Lucida Grande'; font-size: x-small;">Kate Stone</font><span class="" style="font-family: 'Lucida Grande'; font-size: x-small;"> </span><font color="#009193" class="" style="font-family: 'Lucida Grande'; font-size: x-small;"><a href="mailto:k8stone@apple.com" class="">k8stone@apple.com</a></font></div><div class="" style="font-family: Times; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><font face="Lucida Grande" size="1" class=""><font color="#009193" class=""></font> Xcode <font color="#424242" class="">Low Level Tools</font></font></div></div></div></div></div></div>
</div>
<br class=""><div class=""><blockquote type="cite" class=""><div class="">On Aug 15, 2016, at 8:50 AM, David Jones via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org" class="">lldb-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">On Mon, Aug 15, 2016 at 2:36 AM, Pavel Labath via lldb-dev <span dir="ltr" class=""><<a href="mailto:lldb-dev@lists.llvm.org" target="_blank" class="gmail-cremed cremed">lldb-dev@lists.llvm.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I've sampled the python code from the llvm repository, and it seems to<br class="">
be using a mixture of 4-, 2-, and even 8- character indent, with 4<br class="">
being the most prevalent. So, I think we can safely stay with status<br class="">
quo.<br class="">
<br class=""></blockquote><div class=""><br class=""></div><div class="">(Comment from the peanut gallery...)</div><div class=""><br class=""></div><div class="">Python does have a language-level style guide (PEP-8):</div><div class=""><br class=""></div><div class=""><a href="https://www.python.org/dev/peps/pep-0008/" class="">https://www.python.org/dev/peps/pep-0008/</a><br class=""></div><div class=""><br class=""></div><div class="">If code is going to be reformatted, then it may be best to try to converge on exactly the PEP-8 style. Speaking as a project "outsider" (i.e., not an active contributor), but someone with Python background, anything that diverges from standard Python style seems jarring (at least to me).</div><div class=""><br class=""></div><div class=""> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
It will take some editor tweaking to make it use the correct indent<br class="">
for different files, but it should be manageable.<br class="">
<br class="">
pl<br class="">
<div class="gmail-HOEnZb"><div class="gmail-h5"><br class="">
On 12 August 2016 at 18:13, Jim Ingham <<a href="mailto:jingham@apple.com" class="gmail-cremed cremed">jingham@apple.com</a>> wrote:<br class="">
><br class="">
>> On Aug 12, 2016, at 5:23 AM, Pavel Labath via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org" class="gmail-cremed cremed">lldb-dev@lists.llvm.org</a>> wrote:<br class="">
>><br class="">
>> On 12 August 2016 at 00:54, Chris Lattner via lldb-dev<br class="">
>> <<a href="mailto:lldb-dev@lists.llvm.org" class="gmail-cremed cremed">lldb-dev@lists.llvm.org</a>> wrote:<br class="">
>>> I recommend approaching this in three steps:<br class="">
>>><br class="">
>>> 1) get the less-controversial changes done that Greg was outlining.<br class="">
>>> 2) start a discussion in the llvm community about the concept of a<br class="">
>>> member/global prefix.<br class="">
>>> 2a) the community could agree that llvm-as-a-whole should move to prefixes<br class="">
>>> or otherwise change the camel case policy.<br class="">
>>> 2b) the community could agree that the existing policies are preferred<br class="">
>>> 3) LLDB moves to whatever is the end result of the discussion.<br class="">
>>><br class="">
>>> I guess what I’m saying is that since the opinions about this are very<br class="">
>>> strong, and because we haven’t really had that debate in the LLVM community,<br class="">
>>> that it would be bad to proactively move to the LLVM style, simply to have<br class="">
>>> to move back later. Iff the (sure to be extensive) community discussion<br class="">
>>> settles on the idea that prefixes are the wrong thing, then LLDB should<br class="">
>>> remove them to be consistent.<br class="">
>>><br class="">
>>> -Chris<br class="">
>><br class="">
>> +1<br class="">
>><br class="">
>><br class="">
>><br class="">
>> In terms of the formatting of tests, I did some more research on this.<br class="">
>> I think the changes needed to be made to the test suite are generally<br class="">
>> trivial to fix (e.g. r278490), but I don't think we can avoid a manual<br class="">
>> intervention. CommentPragmas does not seem to be a silver bullet -- it<br class="">
>> does prevent clang-format from breaking the comment, but it does not<br class="">
>> prevent it from moving the whole comment to a new line. That said,<br class="">
>> when I reformatted the test sources with CommentPragmas set, the<br class="">
>> number of failures went down to 80 (from about 150)...<br class="">
>><br class="">
>> I believe we should still perform the reformatting of the tests, at<br class="">
>> least to standardize on the 2 space indent (in fact we should consider<br class="">
>> doing the same for the python code as well, I don't know what's the<br class="">
>> situation there in llvm land), but it can be done later. It will make<br class="">
>> the period while the code is in flux longer, but hopefully not too<br class="">
>> long. Also the modifications will be independent of the main reformat,<br class="">
>> so it will still be true that a single source file only got<br class="">
>> reformatted once.<br class="">
>><br class="">
><br class="">
> My eyes put in a vote for not reformatting the Python to 2 space tabs. In C++, most IDE's do smart things with double-clicking on { to find the closing ones easing the task that two space indents makes somewhat harder. But since the spacing is the only nesting indicator in Python, it would be nice to keep that more visually apparent.<br class="">
><br class="">
>> pl<br class="">
>> ______________________________<wbr class="">_________________<br class="">
>> lldb-dev mailing list<br class="">
>> <a href="mailto:lldb-dev@lists.llvm.org" class="gmail-cremed cremed">lldb-dev@lists.llvm.org</a><br class="">
>> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" rel="noreferrer" target="_blank" class="gmail-cremed cremed">http://lists.llvm.org/cgi-bin/<wbr class="">mailman/listinfo/lldb-dev</a><br class="">
><br class="">
______________________________<wbr class="">_________________<br class="">
lldb-dev mailing list<br class="">
<a href="mailto:lldb-dev@lists.llvm.org" class="gmail-cremed cremed">lldb-dev@lists.llvm.org</a><br class="">
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" rel="noreferrer" target="_blank" class="gmail-cremed cremed">http://lists.llvm.org/cgi-bin/<wbr class="">mailman/listinfo/lldb-dev</a><br class="">
</div></div></blockquote></div><br class=""></div></div>
_______________________________________________<br class="">lldb-dev mailing list<br class=""><a href="mailto:lldb-dev@lists.llvm.org" class="">lldb-dev@lists.llvm.org</a><br class=""><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev</a><br class=""></div></blockquote></div><br class=""></div></div>_______________________________________________<br class="">lldb-dev mailing list<br class=""><a href="mailto:lldb-dev@lists.llvm.org" class="">lldb-dev@lists.llvm.org</a><br class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev<br class=""></div></blockquote></div><br class=""></div></div></body></html>