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

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 parses it and spits ou

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

I am a bit late to the party, but anyways, here are my thoughts on the issues here: On 19 September 2016 at 21:18, Zachary Turner via lldb-dev < lldb-dev@lists.llvm.org> wrote: > Difficulty / Effort: 3 (5 if we have to add enhanced mode support) > > Use llvm streams instead of lldb::StreamString >

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

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 wrote: > > > > On Sep 21, 2016,

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

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 &f = *nullptr; It's a > reference. > > I might be a good idea to add an overloaded constructor for nullptr and > void * and delete t

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

> On Sep 21, 2016, at 1:55 PM, Zachary Turner wrote: > > :-/ The same thing happens if you write Foo &f = *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 StringRef from nullptr

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

:-/ The same thing happens if you write Foo &f = *nullptr; It's a reference. Did you try StringRef::withNullAsEmpty()? BTW what code are you converting? I'm working on some of the options code as we speak. On Wed, Sep 21, 2016 at 1:43 PM Greg Clayton wrote: > I am laughing as I convert cod

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

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 > wrote: > > Adding anothe

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

the variable used to be a "const char *" in the last example... > On Sep 21, 2016, at 1:43 PM, Greg Clayton wrote: > > 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

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

Adding another thing to my list (thanks to Mehdi and Eric Christopher for the idea). Apply libfuzzer to LLDB. Details sparse on what parse of LLDB and how, but I think it would be easy to come up with candidates. On Mon, Sep 19, 2016 at 1:18 PM Zachary Turner wrote: > Following up with Kate's

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

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. clang::ASTContex

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

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 a

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

On Tue, Sep 20, 2016 at 2:51 PM Greg Clayton wrote: > > > On Sep 20, 2016, at 2:49 PM, Mehdi Amini wrote: > > > > > >> 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. > > doesn't

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

> 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 zero length and don't >> crash. Just becaus

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

> On Sep 20, 2016, at 2:49 PM, Mehdi Amini wrote: > > >> 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. doesn't StringRef store an actual pointer to ""? This would mean String

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

> 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 > people realize. It

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

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 withNullA

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

> 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 to stay that way, >

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

Also, maybe that code could just return a StringRef. It's like I mentioned a few days ago (don't remember if it was this thread or another), but when you've got StringRefs all the way down, this problem pretty much disappears. On Tue, Sep 20, 2016 at 2:36 PM Zachary Turner wrote: > StringRef ha

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

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 around when the > input i

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

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 e

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

> 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 point you to one exa

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

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 came up previously. > I

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

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 seems to me > like there'

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

> On Sep 20, 2016, at 2:21 PM, Ed Maste via lldb-dev > wrote: > > On 19 September 2016 at 16:18, Zachary Turner via lldb-dev > wrote: >> >> De-inventing the wheel - We should use more code from LLVM, and delete code >> in LLDB where LLVM provides a solution. > > Another example of duplicated

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

Well, but StringRef for example is well documented. So it seems to me like there's an example of a perfectly used assert. It's documented that you can't use null, and if you do it asserts. Just like strlen. The issue I have with "you can't ever assert" is that it brings it into an absolute when

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

A better solution would be to return an error indicating what went wrong with llvm::Error. I really can't believe people are ok with "well you called me with the wrong parameters that aren't documented, I am unhappy and will crash your program" mentality. > On Sep 20, 2016, at 2:11 PM, Adria

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

On 19 September 2016 at 16:18, Zachary Turner via lldb-dev wrote: > > De-inventing the wheel - We should use more code from LLVM, and delete code > in LLDB where LLVM provides a solution. Another example of duplicated code is the debug info parsing (LLDB source/Plugins/SymbolFile/DWARF vs LLVM li

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

Again, strlen is a stupid example as it is well documented. All of llvm and clang are not. > On Sep 20, 2016, at 1:59 PM, Zachary Turner wrote: > > > > 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 assert

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

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 some

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

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 example, > consider this code: > > > > a

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

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 not

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

> 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 written as: assert(p); if

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

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 crash

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

On Tue, Sep 20, 2016 at 4:37 PM, Ted Woodward via lldb-dev < lldb-dev@lists.llvm.org> wrote: > > From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of > Zachary Turner via lldb-dev > Sent: Tuesday, September 20, 2016 12:47 PM > > > This kind of philisophical debate is probably worth

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

From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Zachary Turner via lldb-dev Sent: Tuesday, September 20, 2016 12:47 PM > 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

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

> On Sep 20, 2016, at 10:47 AM, Mehdi Amini wrote: > >> >> 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 Ami

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

> 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*" > > It's like trying to hand

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

> 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 wrote: > > On Sep 19, 2016, at 2:02 PM, Greg Clayt

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

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

> 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 via lldb-dev wrote: > On Sep 19, 2016, at 1:

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

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 it

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

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, strlen(nullptr) will also c

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

BTW, another way to achieve this worthy goal is to require that all the lldb command-line commands be written using the C++ Version of the SB API's. It should be its own module, and the driver should link to that, not directly to the LLDB.framework at all. That would also force us to provide a

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

> 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 inconvenient) to test > the

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

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

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

> 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 extensively, I still > remain

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

> On Sep 19, 2016, at 2:11 PM, Zachary Turner via lldb-dev > 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 complicated needs of a debugge

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

> 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 1:18 PM, Zachary Turner via lldb-dev wrote: Following

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

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 vend it from the ref

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

> 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 > alternative? Are you expecting to check and handle eve

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

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 19

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

> 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 from a few weeks ago, I think the dust has > > settled on the co

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

> 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 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 >>> s

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

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 > not seem practical, and i

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

> 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 complicated needs of a debugger in lit tests.

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

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 over pretty smoothly f

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

> On Sep 19, 2016, at 2:02 PM, Greg Clayton via lldb-dev > wrote: > > >> 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 th

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

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 what about the difficu

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

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 out foundational work

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

> 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 be worth throwing out some ideas for whe

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

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 be worth throwing out some

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

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, and type-safe streaming

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

I'll only comment on the stuff that affects me. > Use llvm streams instead of lldb::StreamString > Supports output re-targeting (stderr, stdout, std::string, etc), printf style > formatting, and type-safe streaming operators. > Interoperates nicely with many existing llvm utility classes > Risk:

[lldb-dev] LLDB Evolution - Final Form

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) th

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

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

Yea it's only clang bots i think On Tue, Sep 6, 2016 at 6:30 AM Pavel Labath via lldb-dev < lldb-dev@lists.llvm.org> wrote: > 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 M

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

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 you referring to? Our bots were red over

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

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 General Failure - Pr

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

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 3 September 2016 at 00:30

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

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 of the bots, what is the

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

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 e

Re: [lldb-dev] LLDB Evolution

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 encourag

Re: [lldb-dev] LLDB Evolution

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 '{t=length($0);su

Re: [lldb-dev] LLDB Evolution

Here it is 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 }' On Sun, Aug 28, 2016 at 9:54 AM Zachary Turner wrote: > I tried that, but most of the results (and there are a

Re: [lldb-dev] LLDB Evolution

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 li

Re: [lldb-dev] LLDB Evolution

Can you just grep for “^“ or something? That seems like a straight-forward way to find lines that have a ton of leading indentation. -Chris > On Aug 27, 2016, at 9:28 AM, Zachary Turner wrote: > > It will probably be hard to find all the cases. Unfortunately

Re: [lldb-dev] LLDB Evolution

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 befo

Re: [lldb-dev] LLDB Evolution

> 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 reason. A huge amount of o

Re: [lldb-dev] LLDB Evolution

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 wrote: > On Aug 26, 2016, a

Re: [lldb-dev] LLDB Evolution

> 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 reason. A huge amount of o

Re: [lldb-dev] LLDB Evolution

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, here's

Re: [lldb-dev] LLDB Evolution

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

On Mon, Aug 8, 2016 at 2:57 PM, Zachary Turner via lldb-dev < lldb-dev@lists.llvm.org> wrote: > > > On Mon, Aug 8, 2016 at 2:40 PM Kate Stone via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > >> LLDB has come a long way since the project was first announced. As a >> robust debugger for C-family

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

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 a

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

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 before. Thanks Zach. > > If I understand

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

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` file to the lldb root

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

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 1

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

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 build-only buildbot is green: h

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

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 already committed to trunk >

[lldb-dev] LLDB Evolution: Next Phase

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 for

Re: [lldb-dev] LLDB Evolution

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, p

Re: [lldb-dev] LLDB Evolution

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 curre

Re: [lldb-dev] LLDB Evolution

> 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 > mailto: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- charact

Re: [lldb-dev] LLDB Evolution

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 with

Re: [lldb-dev] LLDB Evolution

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 file

Re: [lldb-dev] LLDB Evolution

> 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 was outlining. >> 2) start a discussion in the llvm

Re: [lldb-dev] LLDB Evolution

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 prefix. > 2a) the community coul

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).

  1   2   >