<html><body><div>On 13 May, 2011,at 07:01 PM, Douglas Gregor <dgregor@apple.com> wrote:<br><br></div><div><blockquote type="cite"><div class="msg-quote" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; " _mce_style="word-wrap: break-word;"><br><div><div>On May 13, 2011, at 9:55 AM, Erik Verbruggen wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; " _mce_style="word-wrap: break-word;"><br><div><div>On 13 May 2011, at 17:56, Douglas Gregor wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div><br>On May 13, 2011, at 5:13 AM, Erik Verbruggen wrote:<br><br><blockquote type="cite">On 12 May, 2011,at 05:43 PM, Douglas Gregor <<a href="mailto:dgregor@apple.com" _mce_href="mailto:dgregor@apple.com">dgregor@apple.com</a>> wrote:<br></blockquote><blockquote type="cite"><span style="color: rgb(84, 0, 0); "><span style="color: rgb(0, 99, 18); "><br></span></span></blockquote><blockquote type="cite"><blockquote type="cite">However, if the name isn't a simple identifier ("x.operator[]"), then you can still get the location of the start of the member name ("operator"), but when you ask for the range, you'll only get the range of that one token.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Back when we designed libclang, Clang didn't even have the information about where the three tokens of "operator[]" were. Now, we actually have this information via DeclarationNameInfo, so it would make sense to add an API for specifically what you want. Here is a general API that (I think!) could fully solve this problem:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">CXSourceRange clang_getCursorReferenceNameRange(CXCursor C, unsigned NameFlags, unsigned PieceIndex);<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">where C is a cursor that references something else (e.g., a member reference, declaration reference, type reference, etc.), and returns the source range covering the reference itself. The two "unsigned" values would be for configurability:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">- NameFlags could be bitset with three independent flags: WantQualifier (to ask it to include the nested-name-specifier, e.g., Foo:: in x.Foo::y, in the range), WantTemplateArgs (to ask it to include the explicit template arguments, e.g., <int> in x.f<int>, in the range), and WantSinglePiece (described below).<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">- WantPiece/PieceIndex is my attempt at handling cases where the name itself isn't contiguous. For example, imagine the expression "a[y]", which ends up referring to an overloaded operator[]. The source range for the full operator name is, effectively, "[y]", since the name has been split into two parts. However, that's not necessarily useful, so WantPiece would indicate that we want a range covering only one piece of the name, where PieceIndex==0 indicates that we want the '[' and PieceIndex==1 indicates that we want the ']'.<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">So for "operator[]" you would 3 pieces? Or just 1?<br></blockquote><br>Probably just one.<br></div></blockquote></div></div></blockquote></div></div></blockquote><span><div><span><br></span></div>I'm giving it a shot, but I'm running into a couple of problems. For ObjC, </span>ParseObjCMethodDecl does not store the identifier positions, nor the colons. Should I extend the Selector there, or is there another way to get the SourceLocations for those tokens?</div><div><br></div><div>Then for C++, consider:</div><div><br></div><div><div>struct Struct {</div><div> void func();</div><div> int operator[](int);</div><div>};</div><div><br></div><div>void f()</div><div>{</div><div> Struct inst;</div><div> inst.func(); // 1</div><div> inst[1]; // 2</div><div> inst.operator[](1); // 3</div><div>}</div></div><div><span><br></span></div><div><span>Now (1) and (3) are doable, but (2) is a bit tricky: the SourceLocation for the two pieces of the DeclRefExpr are stored in the CXXOperatorCallExpr node as the lparen/rparen location in the CallExpr parent-class. Should these two locations also be stored in the DeclRefExpr, like in case (3)? Or should we leave them where they are and handle case (2) in the same way as case (1)?</span></div><div><span><br></span></div><div><span>Regards,</span></div><div><span>Erik.</span></div><div><span><br></span></div></body></html>