Re: [lldb-dev] LLDB Evolution

> On Aug 11, 2016, at 3:40 PM, Zachary Turner via lldb-dev > wrote: > > > On Thu, Aug 11, 2016 at 3:28 PM Greg Clayton > wrote: > > > - Will we stop putting m_ at the front of class ivars and g_ at > > the front of globals? > > I believe these make thing

Re: [lldb-dev] LLDB Evolution

On Thu, Aug 11, 2016 at 4:05 PM Greg Clayton wrote: > > If we go camel case then debugger_sp would become DebuggerSP. > The problem is that's already the name of the typedef in lldb-forward.h :( Unless we get rid of all those (also not entirely opposed to that TBH).

Re: [lldb-dev] LLDB Evolution

> On Aug 11, 2016, at 3:40 PM, Zachary Turner wrote: > > > On Thu, Aug 11, 2016 at 3:28 PM Greg Clayton wrote: > > > - Will we stop putting m_ at the front of class ivars and g_ at > > the front of globals? > > I believe these make things much clearer and I would love to see llvm a

Re: [lldb-dev] LLDB Evolution

On Thu, Aug 11, 2016 at 3:28 PM Greg Clayton wrote: > > > - Will we stop putting m_ at the front of class ivars and g_ at > the front of globals? > > I believe these make things much clearer and I would love to see llvm and > clang adopt some way to identify member variables. "m_" might

Re: [lldb-dev] LLDB Evolution

> On Aug 11, 2016, at 12:19 PM, Ted Woodward via lldb-dev > wrote: > > I don’t think we can completely get rid of the lldb coding conventions doc; > we’ll need this type of thing as long as we use swig: > > · enumerations that might end up being in the lldb SB API's should all be > written

Re: [lldb-dev] LLDB Evolution

> On Aug 11, 2016, at 11:36 AM, Zachary Turner wrote: > > I was thinking the same thing too. I figured this was just for the interim. > > Chris, did you mean to update the global LLVM style conventions? Yes, I meant that this should get updated: http://llvm.org/docs/CodingStandards.html#inclu

Re: [lldb-dev] LLDB Evolution

> On Aug 11, 2016, at 12:19 PM, Ted Woodward > wrote: > > I don’t think we can completely get rid of the lldb coding conventions doc; > we’ll need this type of thing as long as we use swig: > > · enumerations that might end up being in the lldb SB API's should all be > written like: > >

Re: [lldb-dev] LLDB Evolution

I don’t think we can completely get rid of the lldb coding conventions doc; we’ll need this type of thing as long as we use swig: * enumerations that might end up being in the lldb SB API's should all be written like: typedef enum EnumName { eEnumNameFirstValue,

Re: [lldb-dev] First hand support for musl-libc

On Thu, Aug 11, 2016 at 9:28 AM, Pavel Labath wrote: > On 10 August 2016 at 22:34, Dangling Pointer > wrote: >> Thanks Pavel! I see the changes made in master branch. >> >> >> By any change can these be back-ported to release38 and 39 branches? Since >> llvm38 is the one aports is offering. >> >

Re: [lldb-dev] LLDB Evolution

I was thinking the same thing too. I figured this was just for the interim. Chris, did you mean to update the global LLVM style conventions? On Thu, Aug 11, 2016 at 11:27 AM Jim Ingham wrote: > Shouldn't this be made general and added to the llvm coding conventions? > I was assuming that upon

Re: [lldb-dev] LLDB Evolution

Shouldn't this be made general and added to the llvm coding conventions? I was assuming that upon completion of this exercise, we would delete the lldb coding conventions doc. Jim > On Aug 11, 2016, at 11:20 AM, Zachary Turner via lldb-dev > wrote: > > On Wed, Aug 10, 2016 at 10:37 PM Chris

Re: [lldb-dev] LLDB Evolution

On Wed, Aug 10, 2016 at 10:37 PM Chris Lattner wrote: > > On Aug 9, 2016, at 3:01 PM, Zachary Turner via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > So perhaps it would be reasonable for us to standardize on something like > this: > > >1. Main Module Header >2. Local/Private Headers

Re: [lldb-dev] LLDB Evolution

100% agreed, though we do want to avoid multiple formatting passes over time if at all possible. Having exceptions to the comment formatting rules for the entire test suite subtree is acceptable – presuming we aren’t planning to come back and do another pass where we revisit that decision in th

[lldb-dev] [Bug 28940] New: LLDB calls wrong C++ method when virtual hides non-virtual

https://llvm.org/bugs/show_bug.cgi?id=28940 Bug ID: 28940 Summary: LLDB calls wrong C++ method when virtual hides non-virtual Product: lldb Version: unspecified Hardware: PC OS: All Status: NEW

Re: [lldb-dev] LLDB Evolution

Yea, if you see above, I mentioned that clang-format has a style option called CommentPragmas, which allows you to specify a regex for comments that clang-format won't touch. If you specified CommentPragmas: .* then it would never touch any comment no matter what. (Note that I haven't actually te

Re: [lldb-dev] LLDB Evolution

In fact, the lldbinline tests could be completely broken by clang-formatting them. They treat each //% line as a separate command to execute. If clang-format broke those lines, lldbinline tests would stop working. Sean > On Aug 11, 2016, at 9:57 AM, Chris Lattner via lldb-dev > wrote: > >

Re: [lldb-dev] LLDB Evolution

> On Aug 11, 2016, at 7:41 AM, Pavel Labath wrote: > > I just committed another header cleanup commit, which makes lldb > clang-format-immune ( = it still compiles after a full reformat) on > linux. Other OS's are still likely to have some missed dependencies. Nice! > However, when I tried ru

Re: [lldb-dev] First hand support for musl-libc

On 10 August 2016 at 22:34, Dangling Pointer wrote: > Thanks Pavel! I see the changes made in master branch. > > > By any change can these be back-ported to release38 and 39 branches? Since > llvm38 is the one aports is offering. > I think the 3.8 ship has sailed, but there still may be a chance

[lldb-dev] [Bug 28939] New: test infra: convert pexpect errors into failures

https://llvm.org/bugs/show_bug.cgi?id=28939 Bug ID: 28939 Summary: test infra: convert pexpect errors into failures Product: lldb Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal

Re: [lldb-dev] LLDB Evolution

Hi Christian, I don't think we will need to modify clang-format to resolve this. At most we will need to disable the formatting in some regions. Zachary, I think we should first look at what kind of comment modifications is clang-format doing and whether they are preventing us from doing our stu

Re: [lldb-dev] LLDB Evolution

Can we fix this by putting a .clang-format style file in the tests/ folder that disables comment formatting? The sledgehammer approach would be CommentPragmas: .* But we can probably do it with a combination of more targeted options too On Thu, Aug 11, 2016 at 8:26 AM Christian Convey wrote: >

Re: [lldb-dev] LLDB Evolution

On Thu, Aug 11, 2016 at 11:18 AM, Adrian McCarthy wrote: > I assume Christian Convey was referring to clang-format moving the > "//breakpoint here" comments in the tests to different lines. That's correct. I apologize for the confusion. - Christian __

Re: [lldb-dev] LLDB Evolution

I assume Christian Convey was referring to clang-format moving the "//breakpoint here" comments in the tests to different lines. On Thu, Aug 11, 2016 at 8:15 AM, Zachary Turner via lldb-dev < lldb-dev@lists.llvm.org> wrote: > It's not possible. The problem is that lldb was dependent on order of >

Re: [lldb-dev] LLDB Evolution

It's not possible. The problem is that lldb was dependent on order of includes because each header wasn't properly including what it used. So when clang-format reordered this, things broke On Thu, Aug 11, 2016 at 8:04 AM Christian Convey via lldb-dev < lldb-dev@lists.llvm.org> wrote: > Hi Pavel, >

Re: [lldb-dev] LLDB Evolution

Hi Pavel, Would it make sense to address this problem by fixing clang-format, rather than working around it? (Assuming the clang-format fix is relatively easy, and acceptable to clang-format's maintainers.) - Christian On Thu, Aug 11, 2016 at 10:41 AM, Pavel Labath via lldb-dev wrote: > I just

Re: [lldb-dev] LLDB Evolution

I just committed another header cleanup commit, which makes lldb clang-format-immune ( = it still compiles after a full reformat) on linux. Other OS's are still likely to have some missed dependencies. However, when I tried running the test suite I got about 150 failures. Based on a sample of the