ping?
On Mon, Dec 11, 2017 at 12:55 AM, Davide Italiano <dccitali...@gmail.com> wrote: > ping. Any luck trying to write a testcase? > This is a great opportunity to discuss whether is feasible and we can > improve the testing strategy here. > > -- > Davide > > On Fri, Dec 1, 2017 at 11:02 AM, Davide Italiano <dccitali...@gmail.com> > wrote: >> 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
