> On Aug 14, 2018, at 5:34 PM, Zachary Turner <ztur...@google.com> wrote: > > I’ve thought about this in the past but the conclusion I came to is that > lldbinline tests are actually just filecheck tests in disguise. Why do we > need both? I’d rather delete the lldbinline infrastructure entirely and make > a new lit TestFormat that basically does what lldbinline already does
An inline test does more than simply pattern-matching input. It builds a program, sets breakpoints, etc. I'd rather make this existing infrastructure easier to use than come up with something new. vedant > On Tue, Aug 14, 2018 at 5:31 PM Vedant Kumar via lldb-dev > <lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org>> wrote: > Hello, > > I'd like to make FileCheck available within lldb inline tests, in addition to > existing helpers like 'runCmd' and 'expect'. > > My motivation is that several tests I'm working on can't be made as rigorous > as they need to be without FileCheck-style checks. In particular, the > 'matching', 'substrs', and 'patterns' arguments to runCmd/expect don't allow > me to verify the ordering of checked input, to be stringent about line > numbers, or to capture & reuse snippets of text from the input stream. > > I'd curious to know if anyone else is interested or would be willing to > review this (https://reviews.llvm.org/D50751 > <https://reviews.llvm.org/D50751>). > > Here's an example of an inline test which benefits from FileCheck-style > checking. This test is trying to check that certain frames appear in a > backtrace when stopped inside of the "sink" function. Notice that without > FileCheck, it's not possible to verify the order in which frames are printed, > and that dealing with line numbers would be cumbersome. > > ``` > --- > a/lldb/packages/Python/lldbsuite/test/functionalities/tail_call_frames/unambiguous_sequence/main.cpp > +++ > b/lldb/packages/Python/lldbsuite/test/functionalities/tail_call_frames/unambiguous_sequence/main.cpp > @@ -9,16 +9,21 @@ > > volatile int x; > > +// CHECK: frame #0: {{.*}}sink() at main.cpp:[[@LINE+2]] [opt] > void __attribute__((noinline)) sink() { > - x++; //% self.expect("bt", substrs = ['main', 'func1', 'func2', 'func3', > 'sink']) > + x++; //% self.filecheck("bt", "main.cpp") > } > > +// CHECK-NEXT: frame #1: {{.*}}func3() {{.*}}[opt] [artificial] > void __attribute__((noinline)) func3() { sink(); /* tail */ } > > +// CHECK-NEXT: frame #2: {{.*}}func2() at main.cpp:[[@LINE+1]] [opt] > void __attribute__((disable_tail_calls, noinline)) func2() { func3(); /* > regular */ } > > +// CHECK-NEXT: frame #3: {{.*}}func1() {{.*}}[opt] [artificial] > void __attribute__((noinline)) func1() { func2(); /* tail */ } > > +// CHECK-NEXT: frame #4: {{.*}}main at main.cpp:[[@LINE+2]] [opt] > int __attribute__((disable_tail_calls)) main() { > func1(); /* regular */ > return 0; > ``` > > For reference, here's the output of the "bt" command: > > ``` > runCmd: bt > output: * thread #1, queue = 'com.apple.main-thread', stop reason = > breakpoint 1.1 > * frame #0: 0x000000010c6a6f64 a.out`sink() at main.cpp:14 [opt] > frame #1: 0x000000010c6a6f70 a.out`func3() at main.cpp:15 [opt] > [artificial] > frame #2: 0x000000010c6a6f89 a.out`func2() at main.cpp:21 [opt] > frame #3: 0x000000010c6a6f90 a.out`func1() at main.cpp:21 [opt] > [artificial] > frame #4: 0x000000010c6a6fa9 a.out`main at main.cpp:28 [opt] > ``` > > thanks, > vedant > _______________________________________________ > lldb-dev mailing list > lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > <http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev>
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
