[cfe-dev] Bug 15125 - FunctionDecl::getNameInfo().getEndLoc() is off-by-one for C++ destructors

James Abbatiello abbeyj at gmail.com
Thu Feb 14 11:20:43 PST 2013

Hi Richard,

Thanks for your response.  I'm not familiar with clang internals so I'm
still confused.  How could a TypeSourceInfo be built in this function?  And
what would be done with it one you had it?  The function looks like it is
supposed to return the type of the class, at least if I'm understanding
correctly.  Are you proposing that it instead return the TypeSourceInfo and
other code be refactored?  Or that there's some place to store the
TypeSourceInfo and then retrieve it later in Sema::GetNameFromUnqualifiedId?

James Abbatiello

On Wed, Feb 13, 2013 at 6:00 PM, Richard Smith <richard at metafoo.co.uk>wrote:

> Looks like the root cause here is that Sema::getDestructorName isn't
> building a TypeSourceInfo for the destructor name.
> On Wed, Feb 13, 2013 at 2:23 PM, James Abbatiello <abbeyj at gmail.com>wrote:
>> Hello,
>> I've been looking into http://llvm.org/bugs/show_bug.cgi?id=15125 and I
>> think I have an idea of where the problem is coming from but not how to fix
>> it.  Advice or input of any kind would be welcome.
>> At http://clang.llvm.org/doxygen/DeclarationName_8cpp_source.html#l00578,
>> the  TInfo variable is always NULL in my experiments.  So the code returns
>> NameLoc (the start location) instead of the end.
>> This NULL value comes from
>> http://clang.llvm.org/doxygen/d9/d4f/SemaDecl_8cpp_source.html#l03002.
>> This code calls GetTypeFromParser with the type of the class (a
>> RecordType).  GetTypeFromPointer will then try to dyn_cast this to
>> LocInfoType which gets NULL.  That NULL eventually ends up in TInfo above.
>> At this point we have both the needed SourceLocations in
>> Name.StartLocation and Name.EndLocation but we need a LocInfoType instead.
>> Can I retrieve or construct one that's appropriate here?  Or should the
>> anonymous union in DeclarationNameLoc be extended to be able to hold a
>> TInfo* and an end location when handling one of CXXConstructorName,
>> CXXDestructorName and CXXConversionFunctionName?
>> --
>> James Abbatiello
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130214/62a7c7a1/attachment.html>

More information about the cfe-dev mailing list