yes, that should work, and we should give it at least a shot :)
On Fri, Dec 1, 2017 at 11:01 AM, Zachary Turner <ztur...@google.com> wrote: > As you said a smaller repro is needed, but I'm imagining a case where we can > write a file containing some C++ code that uses a template that LLDB doesn't > understand, compile it with clang to generate some DWARF, and then run > `lldb-test clang-ast a.out`, where the clang-ast subcommand loads the file, > builds an AST out of it, and then dumps the contents of the AST into some > human readable format to stdout. > > If clang won't generate this kind of DWARF, we could always use yaml2obj to > write the dwarf ourselves. > > On Fri, Dec 1, 2017 at 10:49 AM Jim Ingham via lldb-commits > <lldb-commits@lists.llvm.org> wrote: >> >> The immediate failure - not checking for NULL from an API that can return >> NULL - is more the sort of thing you should enforce in code not by testing, >> either by having the API return some kind of empty object that clients can >> deal with in a regular way, or by using something like llvm's forced check >> errors. You wouldn't want to use an assert here because it will be a while >> before lldb can claim to handle every kind of template C++ can produce, so >> you really just want to fail gracefully. However, this API is used in only >> one place in lldb, and is really a subroutine for code comprehension and is >> unlikely to get other uses. So I'm fine with just checking for null at its >> one usage site. >> >> The failure shows that we don't yet support all template kinds in lldb, >> and that we don't have enough testing for a wide variety of C++ template >> types. Adrian found one instance of this failure, but it is in the Swift >> compiler so I need to make a smaller repro case first, then add a test for >> that type. The longer term plan for this was supposed to be getting lldb & >> the llvm dwarf parser unified, writing a test harness independent of lldb >> that you could just cons up and push a wide variety of DWARF at, fuzz test, >> etc. That effort seems to have stalled, however. For the nonce, when we >> find failures like this, we add them to the lldb testsuite. >> >> But the test that we could ingest this one type - once we fix it so we can >> - wouldn't tickle this failure anyway, so that effort is really orthogonal >> to this patch. >> >> Jim >> >> >> > On Nov 30, 2017, at 9:45 PM, Davide Italiano <dccitali...@gmail.com> >> > wrote: >> > >> > On Thu, Nov 30, 2017 at 7:41 PM, Jim Ingham via lldb-commits >> > <lldb-commits@lists.llvm.org> wrote: >> >> Author: jingham >> >> Date: Thu Nov 30 19:41:30 2017 >> >> New Revision: 319516 >> >> >> >> URL: http://llvm.org/viewvc/llvm-project?rev=319516&view=rev >> >> Log: >> >> ClangASTContext::ParseClassTemplateDecl doesn't always succeed. >> >> When it does, it returns a NULL ClassTemplateDecl. Don't use >> >> it if it is NULL... >> >> >> >> <rdar://problem/35672107> >> >> >> > >> > Is there a way to test this? There should be one. >> > Not an expert in the ASTContext, so please feel free to correct me if >> > I'm wrong. >> >> _______________________________________________ >> lldb-commits mailing list >> lldb-commits@lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
