[PATCH] Location and Range unittests for FriendDecl

[Richard Smith]

On Wed, Jul 16, 2014 at 4:34 PM, Nikola Smiljanic <popizdeh at gmail.com>
wrote:

> FunctionDecl has the location for the 'friend' keyword and used it as a
> start location of the whole declaration but that doesn't seem to be right
> for the example you gave:
>
> int inline friend f() { return 0; }
>
> If we do what you suggest this function declaration will start with
> 'friend' and that doesn't seem right, but then again it might be as the
> user is still able to get the NamedDecl from it... Do you want me to change
> the test as use DeclLoc for start even in this case?
>

I just tested this: in the above case the start of the FunctionDecl is the
'int' keyword. If we move the 'friend' keyword to the front, then the start
of the FunctionDecl is the 'friend' keyword. So it seems like the right
thing to do is to take the start of the FunctionDecl as the start of the
FriendDecl.


> On Thu, Jul 17, 2014 at 9:23 AM, Richard Smith <richard at metafoo.co.uk>
> wrote:
>
>> On Mon, Jun 30, 2014 at 10:52 PM, Nikola Smiljanić <popizdeh at gmail.com>
>> wrote:
>>
>>> ================
>>> Comment at: include/clang/AST/DeclFriend.h:148
>>> @@ +147,3 @@
>>> +      SourceLocation DeclLoc = ND->getLocStart();
>>> +      return SourceRange(FriendLoc < DeclLoc ? FriendLoc : DeclLoc,
>>> +                         ND->getLocEnd());
>>> ----------------
>>> Richard Smith wrote:
>>> > This use of `<` is not correct (it'll do the wrong thing in the
>>> presence of macro expansion). `SourceManager::isBeforeInTranslationUnit` is
>>> the right way, but it's hard to get at from here. What does a `friend`
>>> function declaration think its `LocStart` is? Does that include the
>>> `friend` token already? Maybe you can just use that.
>>> This is very unfortunate but getStartLoc depends on the range, it's
>>> whatever beginning of the range is :(
>>>
>>> Note that we need this only for that contrived case of yours ;) where
>>> friend isn't the first token in the declaration. What's worse, having wrong
>>> range in that case or in the presence of macro expansion? Who uses macros
>>> anyway :P
>>>
>>> I tried this but friend keyword and start of NamedDecl point to same
>>> location. Could we already be wrong in this case?
>>>
>>
>> If the start of the `FunctionDecl` already points to the `friend`
>> keyword, then we should be able to use `DeclLoc` in all cases.
>>
>>
>>>
>>> ```
>>> #define DECL void f();
>>> struct A{
>>>   friend DECL
>>> };
>>> ```
>>>
>>> http://reviews.llvm.org/D3906
>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140716/d8b04696/attachment.html>