> On Mar 6, 2019, at 9:43 AM, Zachary Turner <ztur...@google.com> wrote: > > > On Mon, Mar 4, 2019 at 10:32 AM Zachary Turner <ztur...@google.com > <mailto:ztur...@google.com>> wrote: > On Sat, Mar 2, 2019 at 2:56 PM Adrian Prantl <apra...@apple.com > <mailto:apra...@apple.com>> wrote: >> It becomes testable as an independent component, because you can just send >> requests to it and dump the results and see if they make sense. Currently >> there is almost zero test coverage of this aspect of LLDB apart from what >> you can get after going through many levels of indirection via spinning up a >> full debug session and doing things that indirectly result in symbol queries. > > You are right that the type system debug info ingestion and AST > reconstruction is primarily tested end-to-end. > Do you consider this something worth addressing by testing the debug info > ingestion in isolation? > > Wanted to bump this thread for visibility. If nothing else, I'm interested > in an answer to this question. Because if people agree that it would be > valuable to test this going forward, we should work out a plan about what > such tests would look like and how to refactor the code appropriately to make > it possible.
I think it would help me a lot to have a better idea what level of abstraction you are imagining. Could perhaps come up with a mock-up example with some mad-up syntax / API for what such a test could look like? More testing is always desirable, of course, but I'm afraid that we might end up in a situation like we are with yaml2obj, where we can only test really trivial things nicely and all the interesting cases aren't representable at all. -- adrian
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev