Re: [lldb-dev] LLDB Evolution - Final Form

2016-09-28 Thread Zachary Turner via lldb-dev
Just want to add new things as I think of them. On Mon, Sep 19, 2016 at 1:18 PM Zachary Turner wrote: > > >1. > >lldb-cli -- lldb interactive command line. > > A great way to test this would be have a tool as mentioned, and you pass an lldb command to the tool. It

Re: [lldb-dev] LLDB Evolution - Final Form

2016-09-21 Thread Zachary Turner via lldb-dev
The =delete overload of StringRef is also a great idea. It just helped me catch all the places where we were initializing global option tables from const char *s On Wed, Sep 21, 2016 at 2:28 PM Zachary Turner wrote: > On Wed, Sep 21, 2016 at 2:20 PM Greg Clayton

Re: [lldb-dev] LLDB Evolution - Final Form

2016-09-21 Thread Zachary Turner via lldb-dev
On Wed, Sep 21, 2016 at 2:20 PM Greg Clayton wrote: > > > On Sep 21, 2016, at 1:55 PM, Zachary Turner wrote: > > > > :-/ The same thing happens if you write Foo = *nullptr; It's a > reference. > > I might be a good idea to add an overloaded

Re: [lldb-dev] LLDB Evolution - Final Form

2016-09-21 Thread Greg Clayton via lldb-dev
> On Sep 21, 2016, at 1:55 PM, Zachary Turner wrote: > > :-/ The same thing happens if you write Foo = *nullptr; It's a > reference. I might be a good idea to add an overloaded constructor for nullptr and void * and delete them so that we can't implicitly create a

Re: [lldb-dev] LLDB Evolution - Final Form

2016-09-21 Thread Greg Clayton via lldb-dev
I am laughing as I convert code over to using StringRef and I get crashes: if (name == NULL) StringRef is nice enough to implicitly construct a StringRef from NULL or nullptr so that it can crash for me... > On Sep 21, 2016, at 11:09 AM, Zachary Turner via lldb-dev >

Re: [lldb-dev] LLDB Evolution - Final Form

2016-09-21 Thread Greg Clayton via lldb-dev
I agree that for case #1, we must handle that by checking the pointer. Same thing for #2. For #3 we just need to fix the bug in clang. Our case in more of a different issue. The cause of most crashes for us is in the clang::ASTContext class as we try to create types from DWARF.

Re: [lldb-dev] LLDB Evolution - Final Form

2016-09-21 Thread Zachary Turner via lldb-dev
BTW, one more comment about this. If you've got a situation where LLDB is using LLVM in a way that makes LLDB crash, there are 3 possibilities: 1) LLVM / Clang is vending a pointer and we're supposed to be checking it for null. 2) We used the LLVM / Clang API incorrectly causing it to return us

Re: [lldb-dev] LLDB Evolution - Final Form

2016-09-20 Thread Greg Clayton via lldb-dev
> On Sep 20, 2016, at 2:41 PM, Mehdi Amini wrote: > >> >> On Sep 20, 2016, at 2:31 PM, Greg Clayton wrote: >> >> We should avoid crashing if there is a reasonable work around when the input >> is bad. StringRef with NULL is easy, just put NULL and

Re: [lldb-dev] LLDB Evolution - Final Form

2016-09-20 Thread Mehdi Amini via lldb-dev
> On Sep 20, 2016, at 2:46 PM, Zachary Turner wrote: > > Occasionally (and in my experience *very* occasionally), you need to treat "" > as different from null. return an Optional? — Mehdi > But the frequency with which that is really necessary is much lower than >

Re: [lldb-dev] LLDB Evolution - Final Form

2016-09-20 Thread Zachary Turner via lldb-dev
Occasionally (and in my experience *very* occasionally), you need to treat "" as different from null. But the frequency with which that is really necessary is much lower than people realize. It just seems high because of the prevalence of raw pointers. For every other case, you can use

Re: [lldb-dev] LLDB Evolution - Final Form

2016-09-20 Thread Mehdi Amini via lldb-dev
> On Sep 20, 2016, at 2:31 PM, Greg Clayton wrote: > > We should avoid crashing if there is a reasonable work around when the input > is bad. StringRef with NULL is easy, just put NULL and zero length and don't > crash. Just because it is documented, doesn't mean it needs

Re: [lldb-dev] LLDB Evolution - Final Form

2016-09-20 Thread Zachary Turner via lldb-dev
StringRef has `withNullAsEmpty` which I added a few days ago. It will return an empty StringRef. seems to me that should solve most of those kinds of problems. On Tue, Sep 20, 2016 at 2:31 PM Greg Clayton wrote: > We should avoid crashing if there is a reasonable work

Re: [lldb-dev] LLDB Evolution - Final Form

2016-09-20 Thread Greg Clayton via lldb-dev
We should avoid crashing if there is a reasonable work around when the input is bad. StringRef with NULL is easy, just put NULL and zero length and don't crash. Just because it is documented, doesn't mean it needs to stay that way, but I am not going to fight that battle. We should make every

Re: [lldb-dev] LLDB Evolution - Final Form

2016-09-20 Thread Mehdi Amini via lldb-dev
> On Sep 20, 2016, at 2:19 PM, Greg Clayton wrote: > > Again, strlen is a stupid example as it is well documented. All of llvm and > clang are not. IMO that is: 1) A free claim that is easily defeated (to prove you wrong on *all* of LLVM being not document I just have to

Re: [lldb-dev] LLDB Evolution - Final Form

2016-09-20 Thread Ed Maste via lldb-dev
On 20 September 2016 at 17:25, Greg Clayton wrote: > > Well the DWARF code was copied from LLDB into LLVM. The original person > didn't update LLDB to use it, so things diverged. Yeah, sorry I didn't mention that explicitly. I do recall someone pointed that out when this

Re: [lldb-dev] LLDB Evolution - Final Form

2016-09-20 Thread Zachary Turner via lldb-dev
I don't think anyone is ok with that. I just think that a better solution is to document them. Why handle at runtime what is known about at compile time? On Tue, Sep 20, 2016 at 2:24 PM Zachary Turner wrote: > Well, but StringRef for example is well documented. So it

Re: [lldb-dev] LLDB Evolution - Final Form

2016-09-20 Thread Adrian McCarthy via lldb-dev
My concern about this example: void do_something(foo *p) { assert(p); if (p) p->crash(); } Is that by skipping the operation when the pointer is null is that it's not clear what it should do if it's precondition isn't met. Sure, it won't crash, but it's also not going to "do

Re: [lldb-dev] LLDB Evolution - Final Form

2016-09-20 Thread Zachary Turner via lldb-dev
On Tue, Sep 20, 2016 at 1:55 PM Greg Clayton wrote: > > > On Sep 20, 2016, at 1:45 PM, Zachary Turner wrote: > > > > I do agree that asserts are sometimes used improperly. But who's to say > that the bug was the assert, and not the surrounding code? For

Re: [lldb-dev] LLDB Evolution - Final Form

2016-09-20 Thread Sean Callanan via lldb-dev
My 2¢: > assert(p); > int x = *p; > … > assert(ptr); > int x = strlen(ptr); Both of these should either check for null, be in a situation where p is obviously good (e.g., p is data() from a stack-allocated std::vector), or use references. The assertion to my mind is like an admission "I'm

Re: [lldb-dev] LLDB Evolution - Final Form

2016-09-20 Thread Greg Clayton via lldb-dev
> On Sep 20, 2016, at 1:45 PM, Zachary Turner wrote: > > I do agree that asserts are sometimes used improperly. But who's to say that > the bug was the assert, and not the surrounding code? For example, consider > this code: > > assert(p); > int x = *p; Should be

Re: [lldb-dev] LLDB Evolution - Final Form

2016-09-20 Thread Zachary Turner via lldb-dev
I do agree that asserts are sometimes used improperly. But who's to say that the bug was the assert, and not the surrounding code? For example, consider this code: assert(p); int x = *p; Should this assert also not be here in library code? I mean it's obvious that the program is about to

Re: [lldb-dev] LLDB Evolution - Final Form

2016-09-20 Thread Greg Clayton via lldb-dev
> On Sep 20, 2016, at 10:46 AM, Zachary Turner wrote: > > This kind of philisophical debate is probably worthy of a separate thread :) > That being said, I think asserts are typically used in places where the > assert firing means "You're going to crash *anyway*" > >

Re: [lldb-dev] LLDB Evolution - Final Form

2016-09-20 Thread Mehdi Amini via lldb-dev
> On Sep 20, 2016, at 10:33 AM, Greg Clayton wrote: > >> >> On Sep 19, 2016, at 2:46 PM, Mehdi Amini wrote: >> >>> >>> On Sep 19, 2016, at 2:34 PM, Greg Clayton wrote: >>> On Sep 19, 2016, at 2:20 PM, Mehdi Amini

Re: [lldb-dev] LLDB Evolution - Final Form

2016-09-20 Thread Zachary Turner via lldb-dev
This kind of philisophical debate is probably worthy of a separate thread :) That being said, I think asserts are typically used in places where the assert firing means "You're going to crash *anyway*" It's like trying to handle a bad alloc. What are you going to do anyway? You can crash now or

Re: [lldb-dev] LLDB Evolution - Final Form

2016-09-20 Thread Greg Clayton via lldb-dev
> On Sep 19, 2016, at 2:46 PM, Mehdi Amini wrote: > >> >> On Sep 19, 2016, at 2:34 PM, Greg Clayton wrote: >> >>> >>> On Sep 19, 2016, at 2:20 PM, Mehdi Amini wrote: >>> On Sep 19, 2016, at 2:02 PM, Greg Clayton

Re: [lldb-dev] LLDB Evolution - Final Form

2016-09-20 Thread Zachary Turner via lldb-dev
FWIW I added a function to StringRef the other day that looks like this: static StringRef withNullAsEmpty(const char *Str) { return StringRef(Str ? Str : ""); } I've been using this code in converting existing uses of const char * over to StringRef. It's not 100% what you want, but at least

Re: [lldb-dev] LLDB Evolution - Final Form

2016-09-20 Thread Greg Clayton via lldb-dev
But StringRef is a smart string wrapper and it is there for exactly this reason: to make string handling correct. So let us let it be smart and not crash if you make it with null and call .size() on it... > On Sep 19, 2016, at 2:37 PM, Zachary Turner wrote: > > FWIW,

Re: [lldb-dev] LLDB Evolution - Final Form

2016-09-19 Thread Jim Ingham via lldb-dev
> On Sep 19, 2016, at 3:32 PM, Zachary Turner wrote: > > Ok, in that case I agree with you more. We should test the scripting > interface. It's part of the software, it should be treated as such. 100% on > board. But if we find that it is lacking (or even just

Re: [lldb-dev] LLDB Evolution - Final Form

2016-09-19 Thread Zachary Turner via lldb-dev
Ok, in that case I agree with you more. We should test the scripting interface. It's part of the software, it should be treated as such. 100% on board. But if we find that it is lacking (or even just inconvenient) to test the full capabilities of the debugger, we shouldn't force it to. All of

Re: [lldb-dev] LLDB Evolution - Final Form

2016-09-19 Thread Zachary Turner via lldb-dev
Obviously I defer to you on whether testing via the SB API is better than what GDB does or used to do. But these are not the only two systems in the world. Having used both LLDB and LLVM's test suite extensively, I still remain unconvinced that LLDB's testing situation could not be improved. Do

Re: [lldb-dev] LLDB Evolution - Final Form

2016-09-19 Thread Jim Ingham via lldb-dev
> On Sep 19, 2016, at 3:19 PM, Zachary Turner wrote: > > Obviously I defer to you on whether testing via the SB API is better than > what GDB does or used to do. But these are not the only two systems in the > world. Having used both LLDB and LLVM's test suite

Re: [lldb-dev] LLDB Evolution - Final Form

2016-09-19 Thread Mehdi Amini via lldb-dev
> On Sep 19, 2016, at 2:34 PM, Greg Clayton wrote: > >> >> On Sep 19, 2016, at 2:20 PM, Mehdi Amini wrote: >> >>> >>> On Sep 19, 2016, at 2:02 PM, Greg Clayton via lldb-dev >>> wrote: >>> >>> On Sep 19, 2016, at

Re: [lldb-dev] LLDB Evolution - Final Form

2016-09-19 Thread Zachary Turner via lldb-dev
On Mon, Sep 19, 2016 at 2:37 PM Greg Clayton wrote: > > > Just thinking out loud here, but one possibility is to have multiple > pools. One which is ref counted and one which isn't. If you need > something to live forever, vend it from the non-ref-counted pool. > Otherwise

Re: [lldb-dev] LLDB Evolution - Final Form

2016-09-19 Thread Enrico Granata via lldb-dev
> On Sep 19, 2016, at 2:31 PM, Zachary Turner via lldb-dev > wrote: > > > > On Mon, Sep 19, 2016 at 2:20 PM Mehdi Amini > wrote: > > > I’m surprise by your aversion to assertions, what is your suggested >

Re: [lldb-dev] LLDB Evolution - Final Form

2016-09-19 Thread Zachary Turner via lldb-dev
FWIW, strlen(nullptr) will also crash just as easily as StringRef(nullptr) will crash, so that one isn't a particularly convincing example of poorly used asserts, since the onus on the developer is exactly the same as with strlen. That said, I still know where you're coming from :) On Mon, Sep

Re: [lldb-dev] LLDB Evolution - Final Form

2016-09-19 Thread Greg Clayton via lldb-dev
> On Sep 19, 2016, at 2:24 PM, Zachary Turner wrote: > > > > On Mon, Sep 19, 2016 at 2:02 PM Greg Clayton wrote: > > > On Sep 19, 2016, at 1:18 PM, Zachary Turner via lldb-dev > > wrote: > > > > Following up with Kate's post

Re: [lldb-dev] LLDB Evolution - Final Form

2016-09-19 Thread Zachary Turner via lldb-dev
On Mon, Sep 19, 2016 at 2:20 PM Mehdi Amini wrote: > > > I’m surprise by your aversion to assertions, what is your suggested > alternative? Are you expecting to check and handle every possible > invariants everywhere and recover (or signal an error) properly? That does >

Re: [lldb-dev] LLDB Evolution - Final Form

2016-09-19 Thread Greg Clayton via lldb-dev
> On Sep 19, 2016, at 2:11 PM, Zachary Turner wrote: > > > > On Mon, Sep 19, 2016 at 2:02 PM Greg Clayton wrote: > > > • Separate testing tools > > • One question that remains open is how to represent > > the

Re: [lldb-dev] LLDB Evolution - Final Form

2016-09-19 Thread Zachary Turner via lldb-dev
On Mon, Sep 19, 2016 at 2:02 PM Greg Clayton wrote: > > > On Sep 19, 2016, at 1:18 PM, Zachary Turner via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > > > Following up with Kate's post from a few weeks ago, I think the dust has > settled on the code reformat and it went

Re: [lldb-dev] LLDB Evolution - Final Form

2016-09-19 Thread Zachary Turner via lldb-dev
On Mon, Sep 19, 2016 at 2:02 PM Greg Clayton wrote: > > > • Separate testing tools > > • One question that remains open is how to > represent the complicated needs of a debugger in lit tests. Part a) above > covers the trivial cases, but

Re: [lldb-dev] LLDB Evolution - Final Form

2016-09-19 Thread Zachary Turner via lldb-dev
On Mon, Sep 19, 2016 at 1:57 PM Enrico Granata wrote: > > I am definitely not innocent in this regard. However, it does happen for a > reason. > > Sometimes, I am writing code in lldb that is the foundation of something I > need to do over on the Swift.org side. > > I'll lay

Re: [lldb-dev] LLDB Evolution - Final Form

2016-09-19 Thread Enrico Granata via lldb-dev
A few remarks > On Sep 19, 2016, at 1:18 PM, Zachary Turner via lldb-dev > wrote: > > Following up with Kate's post from a few weeks ago, I think the dust has > settled on the code reformat and it went over pretty smoothly for the most > part. So I thought it might

Re: [lldb-dev] LLDB Evolution - Final Form

2016-09-19 Thread Zachary Turner via lldb-dev
On Mon, Sep 19, 2016 at 1:38 PM Sean Callanan wrote: > I'll only comment on the stuff that affects me. > > >1. Use llvm streams instead of lldb::StreamString > 1. Supports output re-targeting (stderr, stdout, std::string, etc), > printf style formatting,

[lldb-dev] LLDB Evolution - Final Form

2016-09-19 Thread Zachary Turner via lldb-dev
Following up with Kate's post from a few weeks ago, I think the dust has settled on the code reformat and it went over pretty smoothly for the most part. So I thought it might be worth throwing out some ideas for where we go from here. I have a large list of ideas (more ideas than time, sadly)

Re: [lldb-dev] LLDB Evolution: Next Phase

2016-09-06 Thread Kate Stone via lldb-dev
This has been in the works long enough to get plans together. If the current state of a bot suggests that manual validation is required then that’s what I’d recommend. That’s the unfortunate current state of affairs with the Green Dragon bots, for example. Kate Stone k8st...@apple.com

Re: [lldb-dev] LLDB Evolution: Next Phase

2016-09-06 Thread Pavel Labath via lldb-dev
Wow, I had no idea things were that bad. LLDB buildbots do not seem to be affected though, so I think we should proceed. pl On 6 September 2016 at 14:09, Ed Maste wrote: > On 6 September 2016 at 08:51, Pavel Labath wrote: >> Hi Ed, >> >> which bots are

Re: [lldb-dev] LLDB Evolution: Next Phase

2016-09-06 Thread Ed Maste via lldb-dev
On 6 September 2016 at 08:51, Pavel Labath wrote: > Hi Ed, > > which bots are you referring to? Our bots were red overnight, but > we've been cleaning them up now, and they should get green shortly. As > far as we're concerned, the reformat can go on as planned. The "Buildbot

Re: [lldb-dev] LLDB Evolution: Next Phase

2016-09-06 Thread Pavel Labath via lldb-dev
Hi Ed, which bots are you referring to? Our bots were red overnight, but we've been cleaning them up now, and they should get green shortly. As far as we're concerned, the reformat can go on as planned. pl On 6 September 2016 at 13:06, Ed Maste via lldb-dev wrote: > On

Re: [lldb-dev] LLDB Evolution: Next Phase

2016-09-06 Thread Ed Maste via lldb-dev
On 3 September 2016 at 00:30, Kate Stone via lldb-dev wrote: > As a reminder, any pending commits you might have planned for LLDB this > weekend must not break any of the bots we’re using to validate the health of > the source tree. Given the current non-functional state

Re: [lldb-dev] LLDB Evolution: Next Phase

2016-09-02 Thread Kate Stone via lldb-dev
As a reminder, any pending commits you might have planned for LLDB this weekend must not break any of the bots we’re using to validate the health of the source tree. Thanks to everyone who nominated a validation process for the pending reformatting. We’ll assume that each of these validation

Re: [lldb-dev] LLDB Evolution

2016-08-30 Thread Pavel Labath via lldb-dev
I would definitely welcome more prolific usage of early returns, but I don't think we can do that before the big reformat. At least some of those changes will be pretty non-trivial and risky. I'd vote for making these changes after the reformat. Hopefully the uglyness of the code will also

Re: [lldb-dev] LLDB Evolution

2016-08-28 Thread Tamas Berghammer via lldb-dev
You can grep for " {$". With this regex I see no false positives and 272 case with 40 or more leading spaces On Sun, 28 Aug 2016, 17:59 Zachary Turner via lldb-dev, < lldb-dev@lists.llvm.org> wrote: > Here it is > > > grep -n '^ \+' . -r -o | awk

Re: [lldb-dev] LLDB Evolution

2016-08-28 Thread Zachary Turner via lldb-dev
I tried that, but most of the results (and there are a ton to wade through) are function parameters that wrapped and align with the opening paren on the next line. Earlier in the thread (i think it was this thread anyway) i posted a bash incantation that will grep the source tree and return all

Re: [lldb-dev] LLDB Evolution

2016-08-27 Thread Zachary Turner via lldb-dev
It will probably be hard to find all the cases. Unfortunately clang-tidy doesn't have a "detect deep indentation" check, but that would be pretty useful, so maybe I'll try to add that at some point (although I doubt I can get to it before the big reformat). Finding all of the egregious cases

Re: [lldb-dev] LLDB Evolution

2016-08-27 Thread Chris Lattner via lldb-dev
> On Aug 26, 2016, at 6:12 PM, Zachary Turner via lldb-dev > wrote: > > Back to the formatting issue, there's a lot of code that's going to look bad > after the reformat, because we have some DEEPLY indented code. LLVM has > adopted the early return model for this

Re: [lldb-dev] LLDB Evolution

2016-08-26 Thread Zachary Turner via lldb-dev
Yea, all I did was copy the code and reduce the indent level. There are other issues with the code that are non-conformant for LLVM style, but clang-format can catch all of those. It can't early indent your code for you :) On Fri, Aug 26, 2016 at 6:17 PM Mehdi Amini

Re: [lldb-dev] LLDB Evolution

2016-08-26 Thread Mehdi Amini via lldb-dev
> On Aug 26, 2016, at 6:12 PM, Zachary Turner via lldb-dev > wrote: > > Back to the formatting issue, there's a lot of code that's going to look bad > after the reformat, because we have some DEEPLY indented code. LLVM has > adopted the early return model for this

Re: [lldb-dev] LLDB Evolution

2016-08-26 Thread Zachary Turner via lldb-dev
Back to the formatting issue, there's a lot of code that's going to look bad after the reformat, because we have some DEEPLY indented code. LLVM has adopted the early return model for this reason. A huge amount of our deeply nested code could be solved by using early returns. For example,

Re: [lldb-dev] LLDB Evolution

2016-08-25 Thread Zachary Turner via lldb-dev
Definitely agree we can't map everything to that model. I can imagine a first step towards lit being where all our tests are literally exactly the same as they are today, with Makefiles and all, but where lit is used purely to recurse the directory tree, run things in multiple processes, and spawn

Re: [lldb-dev] LLDB Evolution: Next Phase

2016-08-24 Thread Pavel Labath via lldb-dev
Sounds like a good idea. After the reformat, we can try it out and see if it works well enough (I don't know how smart that thing is, but I can imagine it could end up quite confused by all the line breaking that clang-format will do). If it works, I will definitely use it. pl On 23 August 2016

Re: [lldb-dev] LLDB Evolution: Next Phase

2016-08-23 Thread Zachary Turner via lldb-dev
Pretty much, yea. On Tue, Aug 23, 2016 at 12:24 PM Ed Maste wrote: > On 23 August 2016 at 11:55, Zachary Turner wrote: > > > > Should we consider adding git hyper-blame to llvm and recommending its > usage? > > Nifty, I hadn't encountered git hyper-blame

Re: [lldb-dev] LLDB Evolution: Next Phase

2016-08-23 Thread Ed Maste via lldb-dev
On 23 August 2016 at 11:55, Zachary Turner wrote: > > Should we consider adding git hyper-blame to llvm and recommending its usage? Nifty, I hadn't encountered git hyper-blame before. Thanks Zach. If I understand correctly all we need to do is add a `.git-blame-ignore-revs`

Re: [lldb-dev] LLDB Evolution: Next Phase

2016-08-23 Thread Zachary Turner via lldb-dev
Should we consider adding git hyper-blame to llvm and recommending its usage? https://commondatastorage.googleapis.com/chrome-infra-docs/flat/depot_tools/docs/html/git-hyper-blame.html On Tue, Aug 23, 2016 at 6:44 AM Ed Maste via lldb-dev < lldb-dev@lists.llvm.org> wrote: > On 19 August 2016 at

Re: [lldb-dev] LLDB Evolution: Next Phase

2016-08-23 Thread Ed Maste via lldb-dev
On 19 August 2016 at 17:10, Kate Stone via lldb-dev wrote: > > Sept 5th Trunk closes for commits while reformatting takes place and is > validated before re-opening trunk. This is fine with me. As for validation, from my perspective I want to make sure the FreeBSD

Re: [lldb-dev] LLDB Evolution: Next Phase

2016-08-22 Thread Pavel Labath via lldb-dev
On 19 August 2016 at 22:10, Kate Stone via lldb-dev wrote: > 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

[lldb-dev] LLDB Evolution: Next Phase

2016-08-19 Thread Kate Stone via lldb-dev
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

Re: [lldb-dev] LLDB Evolution

2016-08-19 Thread Pavel Labath via lldb-dev
I am fine with reformatting the python code as well. BTW, does anyone know if autopep8 (or something similar) has some editor or git integration, in a similar way that clang-format does? It would be great if we could make sure any new code added after that still follows the conventions. cheers,

Re: [lldb-dev] LLDB Evolution

2016-08-18 Thread Kate Stone via lldb-dev
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

Re: [lldb-dev] LLDB Evolution

2016-08-15 Thread Chris Lattner via lldb-dev
> On Aug 15, 2016, at 8:50 AM, David Jones via lldb-dev > wrote: > > On Mon, Aug 15, 2016 at 2:36 AM, Pavel Labath via lldb-dev > > wrote: > I've sampled the python code from the llvm repository, and it seems to

Re: [lldb-dev] LLDB Evolution

2016-08-15 Thread David Jones via lldb-dev
On Mon, Aug 15, 2016 at 2:36 AM, Pavel Labath via lldb-dev < lldb-dev@lists.llvm.org> wrote: > I've sampled the python code from the llvm repository, and it seems to > be using a mixture of 4-, 2-, and even 8- character indent, with 4 > being the most prevalent. So, I think we can safely stay

Re: [lldb-dev] LLDB Evolution

2016-08-15 Thread Pavel Labath via lldb-dev
I've sampled the python code from the llvm repository, and it seems to be using a mixture of 4-, 2-, and even 8- character indent, with 4 being the most prevalent. So, I think we can safely stay with status quo. It will take some editor tweaking to make it use the correct indent for different

Re: [lldb-dev] LLDB Evolution

2016-08-12 Thread Jim Ingham via lldb-dev
> On Aug 12, 2016, at 5:23 AM, Pavel Labath via lldb-dev > wrote: > > On 12 August 2016 at 00:54, Chris Lattner via lldb-dev > wrote: >> I recommend approaching this in three steps: >> >> 1) get the less-controversial changes done that Greg

Re: [lldb-dev] LLDB Evolution

2016-08-12 Thread Pavel Labath via lldb-dev
On 12 August 2016 at 00:54, Chris Lattner via lldb-dev wrote: > I recommend approaching this in three steps: > > 1) get the less-controversial changes done that Greg was outlining. > 2) start a discussion in the llvm community about the concept of a > member/global

Re: [lldb-dev] LLDB Evolution

2016-08-11 Thread Chris Lattner via lldb-dev
> 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

Re: [lldb-dev] LLDB Evolution

2016-08-11 Thread Greg Clayton via lldb-dev
> 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

Re: [lldb-dev] LLDB Evolution

2016-08-11 Thread Zachary Turner via lldb-dev
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

Re: [lldb-dev] LLDB Evolution

2016-08-11 Thread Greg Clayton via lldb-dev
Collaborative Project > > From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Zachary > Turner via lldb-dev > Sent: Thursday, August 11, 2016 1:37 PM > To: Jim Ingham <jing...@apple.com> > Cc: Kate Stone <k8st...@apple.com>; LLDB <lldb-dev@lists.ll

Re: [lldb-dev] LLDB Evolution

2016-08-11 Thread Chris Lattner via lldb-dev
> 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:

Re: [lldb-dev] LLDB Evolution

2016-08-11 Thread Ted Woodward via lldb-dev
-dev Sent: Thursday, August 11, 2016 1:37 PM To: Jim Ingham <jing...@apple.com> Cc: Kate Stone <k8st...@apple.com>; LLDB <lldb-dev@lists.llvm.org> Subject: Re: [lldb-dev] LLDB Evolution I was thinking the same thing too. I figured this was just for the interim. Chris, did

Re: [lldb-dev] LLDB Evolution

2016-08-11 Thread Zachary Turner via lldb-dev
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

Re: [lldb-dev] LLDB Evolution

2016-08-11 Thread Zachary Turner via lldb-dev
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.

Re: [lldb-dev] LLDB Evolution

2016-08-11 Thread Kate Stone via lldb-dev
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

Re: [lldb-dev] LLDB Evolution

2016-08-11 Thread Zachary Turner via lldb-dev
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

Re: [lldb-dev] LLDB Evolution

2016-08-11 Thread Sean Callanan via lldb-dev
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 >

Re: [lldb-dev] LLDB Evolution

2016-08-11 Thread Chris Lattner via lldb-dev
> 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! >

Re: [lldb-dev] LLDB Evolution

2016-08-11 Thread Pavel Labath via lldb-dev
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

Re: [lldb-dev] LLDB Evolution

2016-08-11 Thread Zachary Turner via lldb-dev
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

Re: [lldb-dev] LLDB Evolution

2016-08-11 Thread Christian Convey via lldb-dev
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

2016-08-11 Thread Adrian McCarthy via lldb-dev
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

2016-08-11 Thread Zachary Turner via lldb-dev
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

2016-08-11 Thread Christian Convey via lldb-dev
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

Re: [lldb-dev] LLDB Evolution

2016-08-11 Thread Pavel Labath via lldb-dev
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

Re: [lldb-dev] LLDB Evolution

2016-08-10 Thread Chris Lattner via lldb-dev
On Aug 9, 2016, at 8:42 AM, Zachary Turner via lldb-dev wrote: > #2 could potentially be improved by lit style tests. +1 to this. > Again, the real question is just how much effort are we actually prepared to > put into this? I'd love it if there were entire days

Re: [lldb-dev] LLDB Evolution

2016-08-10 Thread Chris Lattner via lldb-dev
> On Aug 9, 2016, at 3:01 PM, Zachary Turner via lldb-dev > wrote: > > So perhaps it would be reasonable for us to standardize on something like > this: > > Main Module Header > Local/Private Headers > lldb/... > llvm/... > System #includes This makes sense to me,

Re: [lldb-dev] LLDB Evolution

2016-08-10 Thread Pavel Labath via lldb-dev
I've started to do some cleanup of the include header order (r278222). It doesn't get everything compiling after a clang-format, but it got me about half way. +1 on the include order proposed by Zach. I agree that better modularization would improve testability and have a positive impact on the

Re: [lldb-dev] LLDB Evolution

2016-08-09 Thread Zachary Turner via lldb-dev
Standardizing include order would really help. LLVM's style is documented here , 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

Re: [lldb-dev] LLDB Evolution

2016-08-09 Thread Kate Stone via lldb-dev
Agreed that better layering and modularization is a worthwhile longer-term goal. These kinds of changes should be researched and proposed for discussion because code reorganization can be extremely disruptive (which is why we opened this comment period for the proposed reformatting!) I’d

Re: [lldb-dev] LLDB Evolution

2016-08-09 Thread Kate Stone via lldb-dev
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

Re: [lldb-dev] LLDB Evolution

2016-08-09 Thread Zachary Turner via lldb-dev
On Mon, Aug 8, 2016 at 2:40 PM Kate Stone via lldb-dev < 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

Re: [lldb-dev] LLDB Evolution

2016-08-09 Thread Konstantin Tokarev via lldb-dev
09.08.2016, 18:42, "Zachary Turner via lldb-dev" : > There are a lot of reasons for the lack of tests.  Off the top of my head, > two of the biggest ones are: > > 1) Some areas of LLDB have been historically hard to test.  The unwinder and > core dumps come to mind. 

  1   2   >