<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Jan 22, 2009, at 6:08 PM, Chris Lattner wrote:</div><blockquote type="cite"><div>On Jan 22, 2009, at 8:16 AM, Douglas Gregor wrote:<font class="Apple-style-span" color="#540000"><br></font><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">+ // Permit typedefs without declarators as a Microsoft extension.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">if (!DS.isMissingDeclaratorOk()) {<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">+ if (getLangOptions().Microsoft &&<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">+ DS.getStorageClassSpec() == DeclSpec::SCS_typedef) {<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">+ Diag(DS.getSourceRange().getBegin(), diag::ext_no_declarators)<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">+ << DS.getSourceRange();<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">+ return Tag;<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">+ }<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">This touches on meta-design issues, but do you think it is better to test for getLangOptions.MS here, or do you think it is better to have the Clang driver map this onto ERROR by default when not is ms extensions mode? Both approaches work, but they have different tradeoffs. I'm curious what you (and others!) think.<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">It's an apt meta-issue, but I think in this case, since it's also a GNU extension, it should be an EXTWARN regardless of dialect. On the meta-issue itself, I think I like having the Clang driver make decisions between WARNING/EXTWARN/EXTENSION, but to me it seems like switching a diagnostic from or to ERROR is just asking for trouble: even if it works when we initially do it, we're likely to evolve Sema or the Parser to assume that an error really is an error, and screw up processing when that error turns out not to be an error.<br></blockquote><br>It doesn't matter in this case anymore, however, the point that I was trying to make was that LangOptions and fine-grain warning control are very similar in some cases. In this case, the compiler (including down-stream clients) clearly has to be able to handle this feature. Using a langoption to control a warning just seems strange...<br></div></blockquote></div><br><div>Yeah, I agree with that. When a diagnostic doesn't actually effect what the compiler is going to do, we shouldn't be checking LangOptions to decide whether to emit the warning; the diagnostics system can make that decision.</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>- Doug<br></div></body></html>