<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Oct 20, 2011, at 5:36 PM, Chandler Carruth wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div class="gmail_quote">On Thu, Oct 20, 2011 at 5:12 PM, Richard Trieu <span dir="ltr"><<a href="mailto:rtrieu@google.com">rtrieu@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div>Should Clang be printing suffixes that are accepted only with certain flags?</div><div class="im"><div></div></div></blockquote></div><div><br></div><div>I think this is an interesting policy decision. I'd love to hear Doug's thoughts on it.</div>
<div><br></div><div>It seems fine to me for Clang, when running with -fms-extensions, to suggest fixes even if only valid for -fms-extensions. Clearly if there is a generic suggestion that could be made, that would be a preferred alternative. For example, '__asm__' should be suggested before 'asm'.</div></blockquote><br></div><div>I think it's fine for Clang to print suffixes that are only accepted with certain flags. Presumably, you should never get an IntegerLiteral of type __int128_t unless you're in a dialect that supports parsing it.</div><div><br></div><div>… except that we cheat when we're building template arguments, because it was convenient. That cheating could be eliminated by encoding integer literal values directly within SubstNonTypeTemplateParmExpr.</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>- Doug</div><br></body></html>