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

[Davide Italiano via lldb-commits]

ping?

On Mon, Dec 11, 2017 at 12:55 AM, Davide Italiano <dccitaliano at 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 <dccitaliano at 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 <zturner at 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 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