PR19352 getLocation() points to the wrong position for FriendDecls

Nikola Smiljanic popizdeh at gmail.com
Sat May 10 02:38:06 PDT 2014


I figured out what's going on, I was initially trying to use the location
returned by getTypeSpecTypeNameLoc but decided against it once I saw the
assert in this function. Using the location from TypeSourceInfo does seem
to give more consistent result. Location always points to whatever comes
after 'friend' keyword. The change itself is a oneliner. Are you guys happy
with this version?


On Fri, May 9, 2014 at 11:55 AM, Nikola Smiljanic <popizdeh at gmail.com>wrote:

> You're absolutely right. But I'm seeing something strange now, location
> points to 'class A' and not 'A'. Same with fully qualified names. Has there
> been a recent change that did this? And more importantly are you happy with
> this as FriendDecl's location?
>
>
> On Fri, May 9, 2014 at 9:43 AM, Richard Smith <richard at metafoo.co.uk>wrote:
>
>> Can you use TSI->getTypeLoc().getLocStart() instead of wiring through a
>> new SourceLocation?
>>
>>
>> On Thu, May 8, 2014 at 4:37 PM, Nikola Smiljanic <popizdeh at gmail.com>wrote:
>>
>>> Nudge nudge :)
>>>
>>>
>>> On Tue, Apr 29, 2014 at 5:35 PM, Manuel Klimek <klimek at google.com>wrote:
>>>
>>>> +richard
>>>>
>>>> This makes sense to me, but I don't understand the code well enough to
>>>> approve... Looping in Richard for an expert opinion ;)
>>>>
>>>>
>>>> On Tue, Apr 29, 2014 at 5:13 AM, Nikola Smiljanic <popizdeh at gmail.com>wrote:
>>>>
>>>>> Ping.
>>>>>
>>>>>
>>>>> On Wed, Apr 16, 2014 at 8:38 PM, Nikola Smiljanic <popizdeh at gmail.com>wrote:
>>>>>
>>>>>> LocStart in CheckFriendTypeDecl is the start of DeclSpec range. This
>>>>>> is OK for checking that declaration starts with 'friend' keyword but is
>>>>>> redundant when it comes to FriendDecl creation. Location of the keyword is
>>>>>> already passed as FriendLoc.
>>>>>>
>>>>>> I've added another parameter to this function that points to location
>>>>>> of the type from the declaration. The call to CheckFriendTypeDecl from
>>>>>> SemaTemplateInstantiateDecl now isn't technically correct because it's
>>>>>> passing the the type location as LocStart. But the error that's checked for
>>>>>> using this parameter can only happen inside class declaration, not
>>>>>> instantiated template, I think :)
>>>>>>
>>>>>> Is there a way to test this? I'm not seeing any regressions.
>>>>>>
>>>>>> struct A{};
>>>>>> typedef A Atypedef;
>>>>>>
>>>>>> namespace ns { struct B{}; }
>>>>>>
>>>>>>  template <typename T>
>>>>>> class C
>>>>>> {
>>>>>> friend class A; // points to A
>>>>>> friend Atypedef; // points to Atypedef
>>>>>> friend T; //  points to T
>>>>>> friend decltype(whatever); // points to decltype
>>>>>> friend ns::B; // points to B
>>>>>> friend typename T::something; // points to something
>>>>>> }
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140510/96987bf5/attachment.html>
-------------- next part --------------
diff --git a/lib/Sema/SemaDeclCXX.cpp b/lib/Sema/SemaDeclCXX.cpp
index 54a332a..a10e8ff 100644
--- a/lib/Sema/SemaDeclCXX.cpp
+++ b/lib/Sema/SemaDeclCXX.cpp
@@ -11432,7 +11432,9 @@ FriendDecl *Sema::CheckFriendTypeDecl(SourceLocation LocStart,
   //   If the type specifier in a friend declaration designates a (possibly
   //   cv-qualified) class type, that class is declared as a friend; otherwise,
   //   the friend declaration is ignored.
-  return FriendDecl::Create(Context, CurContext, LocStart, TSInfo, FriendLoc);
+  return FriendDecl::Create(Context, CurContext,
+                            TSInfo->getTypeLoc().getLocStart(), TSInfo,
+                            FriendLoc);
 }
 
 /// Handle a friend tag declaration where the scope specifier was


More information about the cfe-commits mailing list