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

[Richard Smith]

On Fri, Feb 15, 2013 at 1:56 PM, James Abbatiello <abbeyj at gmail.com> wrote:

> I managed to get something close by hacking Sema::GetNameForDeclarator
> like so:
> DeclarationNameInfo Sema::GetNameForDeclarator(Declarator &D) {
>   DeclarationNameInfo ret = GetNameFromUnqualifiedId(D.getName());
>   if (D.getName().getKind() == UnqualifiedId::IK_DestructorName &&
>       ret.getName() &&
>       !ret.getNamedTypeInfo())
>   {
>     ret.setNamedTypeInfo(GetTypeForDeclarator(D, NULL));
>   }
>   return ret;
> }
>
>
> I couldn't figure out how to do something similar from
> Sema::getDestructorName since there's no Declarator available there.  And
> if I try to use getTrivialTypeSourceInfo from getDestructorName then I run
> into two problems:
>
> 1) I only have the QualType for the class, not for the destructor itself
> 2) Even if I make a QualType with Context.getFunctionType,
> getTrivialTypeSourceInfo only takes one SourceLocation
>

getDestructorName returns a ParsedType for the T in ~T, so you don't need a
Declarator, and shouldn't be building a function type.


> Even with the above patch I still have a problem in that the source range
> covers not only the tilde and the name but also the opening and closing
> parentheses.
>
> If anybody has any advice for me, I'd love to hear it.  I'm rather stuck
> at the moment.
>
> --
> James Abbatiello
>
>
>
> On Thu, Feb 14, 2013 at 3:23 PM, Richard Smith <richard at metafoo.co.uk>wrote:
>
>> On Thu, Feb 14, 2013 at 11:20 AM, James Abbatiello <abbeyj at gmail.com>wrote:
>>
>>> 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?
>>>
>>
>> ParsedType can hold the TypeSourceInfo, via the LocInfoType you
>> discovered; use Sema::CreateParsedType to create the ParsedType. You can
>> build an appropriate TypeSourceInfo using
>> ASTContext::getTrivialTypeSourceInfo(QualType, SourceLocation).
>>
>>
>>> --
>>> 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/20130215/2d930b03/attachment.html>