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

[James Abbatiello]

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

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/98ca8fdf/attachment.html>