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
