[cfe-dev] Bug 15125 - FunctionDecl::getNameInfo().getEndLoc() is off-by-one for C++ destructors
richard at metafoo.co.uk
Thu Feb 14 12:23:55 PST 2013
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
> 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:
>>> 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
>>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-dev