Re: [lldb-dev] [llvm-dev] [Release-testers] [7.0.0 Release] rc1 has been tagged

On 16 Aug 2018, at 00:51, Joerg Sonnenberger via llvm-dev wrote: > > On Tue, Aug 07, 2018 at 09:49:16PM +0200, Dimitry Andric via llvm-dev wrote: >> This is a regression caused by https://reviews.llvm.org/rL323281: >> >> >

Re: [lldb-dev] [llvm-dev] [Release-testers] [7.0.0 Release] rc1 has been tagged

On Tue, Aug 07, 2018 at 09:49:16PM +0200, Dimitry Andric via llvm-dev wrote: > This is a regression caused by https://reviews.llvm.org/rL323281: > > > r323281 | wmi | 2018-01-23 23:27:57 + (Tue, 23 Jan 2018) | 12 lines >

Re: [lldb-dev] Using FileCheck in lldb inline tests

They add support for injecting artificial tail call frames into a StackFrameList. D50478 is the first one -- there's no SB API extension in the initial patch, although that's planned. For context, tail calling frames go missing in backtraces because the frame of

Re: [lldb-dev] Using FileCheck in lldb inline tests

What do your patches do, out of curiosity? On Wed, Aug 15, 2018 at 12:45 PM Vedant Kumar wrote: > > On Aug 15, 2018, at 12:27 PM, Zachary Turner wrote: > > Back to the original proposal, my biggest concern is that a single inline > test could generate many FileCheck invocations. This could cau

Re: [lldb-dev] Using FileCheck in lldb inline tests

> On Aug 15, 2018, at 12:27 PM, Zachary Turner wrote: > > Back to the original proposal, my biggest concern is that a single inline > test could generate many FileCheck invocations. This could cause measurable > performance impact on the test suite. Have you considered this? That's a good

Re: [lldb-dev] Using FileCheck in lldb inline tests

Back to the original proposal, my biggest concern is that a single inline test could generate many FileCheck invocations. This could cause measurable performance impact on the test suite. Have you considered this? Another possible solution is what i mentioned earlier, basically to expose a debug

Re: [lldb-dev] Using FileCheck in lldb inline tests

> On Aug 15, 2018, at 12:12 PM, Jason Molenda wrote: > > > >> On Aug 15, 2018, at 11:34 AM, Vedant Kumar wrote: >> >> >> >>> On Aug 14, 2018, at 6:19 PM, Jason Molenda wrote: >>> >>> It's more verbose, and it does mean test writers need to learn the public >>> API, but it's also much m

Re: [lldb-dev] Using FileCheck in lldb inline tests

> On Aug 15, 2018, at 11:34 AM, Vedant Kumar wrote: > > > >> On Aug 14, 2018, at 6:19 PM, Jason Molenda wrote: >> >> It's more verbose, and it does mean test writers need to learn the public >> API, but it's also much more stable and debuggable in the future. > > I'm not sure about this.

Re: [lldb-dev] Using FileCheck in lldb inline tests

> On Aug 15, 2018, at 10:15 AM, Jim Ingham via lldb-dev > wrote: > > > >> On Aug 14, 2018, at 7:48 PM, Zachary Turner via lldb-dev >> wrote: >> >> >> On Tue, Aug 14, 2018 at 6:58 PM Jason Molenda wrote: >> >> >>> On Aug 14, 2018, at 6:39 PM, Zachary Turner wrote: >>> >>> Having bugs

Re: [lldb-dev] Using FileCheck in lldb inline tests

> On Aug 14, 2018, at 6:58 PM, Jason Molenda wrote: > > > >> On Aug 14, 2018, at 6:39 PM, Zachary Turner wrote: >> >> Having bugs also makes the debugger harder to innovate in the future because >> it’s, not having tests leads to having bugs, and sb api tests leads to not >> having tests.

Re: [lldb-dev] Using FileCheck in lldb inline tests

> On Aug 14, 2018, at 6:19 PM, Jason Molenda wrote: > > It's more verbose, and it does mean test writers need to learn the public > API, but it's also much more stable and debuggable in the future. I'm not sure about this. Having looked at failing sb api tests for a while now, I find them ab

Re: [lldb-dev] Using FileCheck in lldb inline tests

> On Aug 14, 2018, at 6:39 PM, Zachary Turner wrote: > > Having bugs also makes the debugger harder to innovate in the future because > it’s, not having tests leads to having bugs, and sb api tests leads to not > having tests. Yeah, this might be a bit of an under-appreciated point. If ther

Re: [lldb-dev] Using FileCheck in lldb inline tests

> On Aug 14, 2018, at 6:07 PM, Zachary Turner wrote: > > > > On Tue, Aug 14, 2018 at 5:56 PM Vedant Kumar > wrote: > > >> On Aug 14, 2018, at 5:34 PM, Zachary Turner > > wrote: >> >> I’ve thought about this in the past but the conclusion I

Re: [lldb-dev] Failing LIT-based lldb-mi tests

> On Aug 15, 2018, at 10:31 AM, Александр Поляков > wrote: > > I built an lldb myself. As far as I remember, this error has been seen in > swift's CI on machines running Linux. Adrian, could you correct me if I'm > wrong? > Yes, we have seen these test fail regularly, but I don't have any

Re: [lldb-dev] Failing LIT-based lldb-mi tests

I built an lldb myself. As far as I remember, this error has been seen in swift's CI on machines running Linux. Adrian, could you correct me if I'm wrong? On Wed, Aug 15, 2018 at 8:02 PM wrote: > That definitely points to an issue with either your install or your system. > > > > Is that an lldb

Re: [lldb-dev] Using FileCheck in lldb inline tests

> On Aug 14, 2018, at 7:48 PM, Zachary Turner via lldb-dev > wrote: > > > On Tue, Aug 14, 2018 at 6:58 PM Jason Molenda wrote: > > > > On Aug 14, 2018, at 6:39 PM, Zachary Turner wrote: > > > > Having bugs also makes the debugger harder to innovate in the future > > because it’s, not ha

Re: [lldb-dev] Failing LIT-based lldb-mi tests

That definitely points to an issue with either your install or your system. Is that an lldb you built, or one you installed with apt-get? Turning on the lldb-server logs might help. Unfortunately, I forget how to do that 😊. Pavel, do you remember? From: Александр Поляков Sent: Tuesda

Re: [lldb-dev] [cfe-dev] stable layout bug for imported record decls.

Just sending again the trace, because gmail broke the lines pretty badly. (1) === "To" ASTContext A, "From" ASTContext X, MINIMAL import through ExternalASTSource inteface clang::ASTImporter::Import (this=0x13b3c50, FromT=...) at ../../git/llvm/tools/clang/lib/AST/ASTImporter.cpp:6983 lldb_privat

Re: [lldb-dev] [cfe-dev] stable layout bug for imported record decls.

Lang, I've done some more research on this and here is what I've found so far. LLDB uses the ExternalASTSource interface and it provides its own implementation for it (lldb_private::ClangASTSource). ClangASTSource is being used in at least 3 modes (all of these uses the ASTImporter): (1) to do a