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

[Davide Italiano via lldb-commits]

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