
<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Jan 23, 2012, at 9:27 AM, Chandler Carruth wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div class="gmail_quote">On Mon, Jan 23, 2012 at 8:58 AM, Argyrios Kyrtzidis <span dir="ltr"><<a href="mailto:akyrtzi@gmail.com">akyrtzi@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto; ">

<div id=":8qh">Improve Lexer::getImmediateMacroName to take into account inner macros<br>

of macro arguments.<br>

<br>

For "MAC1( MAC2(foo) )" and location of 'foo' token it would return<br>

"MAC1" instead of "MAC2".</div></blockquote></div><br><div>This comment, and the comment on the static helper in the DiagnosticRenderer are at odds... which one is it that returns MAC2 and which one MAC1?</div></blockquote><div><br></div><div>On the above message, I say what Lexer::getImmediateMacroName did *before* the commit. On code comments I say what it does now.</div><div>Lexer::getImmediateMacroName will return "MAC2"</div><div>the static helper in DiagnosticRenderer will return "MAC1"</div><br><blockquote type="cite">

<div><br></div><div>It would be good (i think) to call only one of them "immediate", the one returning MAC2.</div></blockquote><div><br></div><div>This or see if DiagnosticRenderer can use the Lexer one.</div><br><blockquote type="cite"><div><br></div><div>Does this impact diagnostic output in any way? If so could you include a testcase that demonstrates that impact?</div>

</blockquote><br></div><div>DiagnosticRenderer was dependent on the previous behavior, test/Misc/caret-diags-macros.c would fail; just change the DiagnosticRenderer to use the Lexer one and you'll see.</div><br></body></html>