<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On May 29, 2012, at 6:24 PM, Chandler Carruth wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div class="gmail_quote">On Tue, May 29, 2012 at 5:34 PM, Anna Zaks <span dir="ltr"><<a href="mailto:ganna@apple.com" target="_blank">ganna@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div id=":6sb">+ // If the function is defined as a builtin macro, do not show macro<br>
+ // expansion.<br>
+ SourceLocation SL = SizeOfArg->getExprLoc();<br>
+ SourceRange DSR = Dest->getSourceRange();<br>
+ SourceRange SSR = SizeOfArg->getSourceRange();<br>
+ SourceManager &SM = PP.getSourceManager();<br>
+<br>
+ if (SM.isMacroArgExpansion(SL)) {<br>
+ ReadableName = Lexer::getImmediateMacroName(SL, SM, LangOpts);<br>
+ SL = SM.getSpellingLoc(SL);<br>
+ DSR = SourceRange(SM.getSpellingLoc(DSR.getBegin()),<br>
+ SM.getSpellingLoc(DSR.getEnd()));<br>
+ SSR = SourceRange(SM.getSpellingLoc(SSR.getBegin()),<br>
+ SM.getSpellingLoc(SSR.getEnd()));<br>
+ }</div></blockquote></div><br><div>I'm not terribly fond of this kind of highly customized printing logic when we may not even emit the diagnostic.</div><div><br></div></blockquote><div><br></div><div>Are you concerned about performance? I doubt that this warning is triggered much and I only added retrieval of more suitable source location information in case the faulty call is a builtin macro.</div><div><br></div><div>As is the warning quality is unacceptable when memcpy(and others) are defined as builtins:</div><div><br></div><div>-/Users/anya/tmp/ex.m:3:27: warning: argument to 'sizeof' in '__builtin___memcpy_chk' call is the same expression as the</div><div><div>- destination; did you mean to dereference it? [-Wsizeof-pointer-memaccess]</div><div>- memcpy(to, from, sizeof(to));</div><div>- ~~~~~~~~~~~~~~~~~~~~~~~~^~~~</div><div>-/usr/include/secure/_string.h:55:41: note: expanded from macro 'memcpy'</div><div>- ? __builtin___memcpy_chk (dest, src, len, __darwin_obsz0 (dest)) \</div><div><br></div><div><div>+/Users/anya/tmp/ex.m:3:27: warning: argument to 'sizeof' in memcpy' call is the same expression as the</div><div>+ destination; did you mean to dereference it? [-Wsizeof-pointer-memaccess]</div><div>+ memcpy(to, from, sizeof(to));</div><div> ~~~~~~~~~~~~~~~~~~~~~~~~^~~~</div><div><br></div></div><div><br></div></div><blockquote type="cite"><div>I wonder -- can we construct this information from within the diagnostic printer, and get it to fire in more circumstances? If not, is there a way to simply tell the diagnostic engine the intent -- to print the builtin name -- rather than hard coding the logic to get from here to there?</div>
</blockquote></div><div><br></div><div><div>I agree that we should come up with a better solution for handling builtin printing, which would apply in all cases. Since diagnostic engine works with SourceLocations, I am not sure it can detect if a location is a builtin or not. Teaching it to print builtins sounds like a plausible idea. However, we might be breaking the abstraction by doing that. (We might as well teach it about printing functions.) I am not very well familiar with that code.</div><div><br></div><div>This band-aid fix can be removed after the proper solution is in place.</div></div><div><br></div><div>Anna.</div></body></html>