<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Feb 1, 2012, at 8:51 AM, Ted Kremenek 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; "><div><div>On Feb 1, 2012, at 8:46 AM, Douglas Gregor wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div>*That* is a general flag that affects every diagnostic Clang can emit. It controls a formatting policy. </div><div><br></div><div>What you're proposing is a flag that tweaks the wording of two specific diagnostics. It's too narrow in scope to warrant a special flag.</div><div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>More generally, I can see different clients wanting to control the diagnostic output of the compiler. We can look for a general solution here; e.g., a single flag that can control various diagnostic options.</div></div></blockquote></div><div><br></div><div>Options that control general policies (color, word-wrapping, macro/template depth, carets, Fix-Its, ranges) all make sense. Options that tweak the wording of specific diagnostics don't, because it's not a useful thing for a user to think about ("oh, I *would* like that diagnostic to have a slightly different wording. let me go modify my build settings…") and because this solution just doesn't scale if we start resolving "what's the best wording?" discussions by adding a flag.</div></span></blockquote></div><br><div>I agree in principle, but this isn't an academic problem. For clients (e.g., an IDE) that don't want to include the #error or #warning in the diagnostic, because they have diagnostic categories to show to user, what would you propose as the solution?</div></div></blockquote></div><div><br></div>My suggestion is to never include the #error or #warning, nor any text to explicitly stating that this diagnostic comes from a #warning or #error. It provides no value to any client that maps the error over to source code (whether it be through the caret diagnostics, range highlighting/jump-to-error in an IDE, or just plan looking at the line number). And I can't bring myself to care about clients that don't map the error over to source code, because this particular set of diagnostics is just the tip of the iceberg for those clients who willfully throw out all of the useful information we provide.<div><div><br><div><span class="Apple-tab-span" style="white-space:pre"> </span>- Doug</div></div></div></body></html>