[Lldb-commits] [lldb] r319516 - ClangASTContext::ParseClassTemplateDecl doesn't always succeed.

[Zachary Turner via lldb-commits]

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 at 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 <dccitaliano at gmail.com>
> wrote:
> >
> > On Thu, Nov 30, 2017 at 7:41 PM, Jim Ingham via lldb-commits
> > <lldb-commits at 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 at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20171201/c16798c5/attachment.html>