<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Jan 31, 2012, at 6:10 PM, Chandler Carruth wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div class="gmail_quote">On Tue, Jan 31, 2012 at 6:00 PM, Douglas Gregor <span dir="ltr"><<a href="mailto:dgregor@apple.com">dgregor@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
Sent from my iPhone<br>
<div class="im"><br>
On Jan 31, 2012, at 1:39 PM, Eric Christopher <<a href="mailto:echristo@apple.com">echristo@apple.com</a>> wrote:<br>
<br>
><br>
> On Jan 31, 2012, at 12:35 PM, Ted Kremenek wrote:<br>
><br>
>> On Jan 31, 2012, at 12:29 PM, Dmitri Gribenko wrote:<br>
>><br>
>>> On Tue, Jan 31, 2012 at 10:17 PM, Ted Kremenek <<a href="mailto:kremenek@apple.com">kremenek@apple.com</a>> wrote:<br>
>>>> I received some feedback from some users who wondered why #error/#warning diagnostics include the actual "#error" in the diagnostic, e.g.:<br>
>>>><br>
>>>> t.c:1:2: error: #error this is an error<br>
>>>><br>
>>>> This seems redundant. Is this necessary?<br>
>>><br>
>>> It marks explicitly diagnostics that come from source code (as opposed<br>
>>> to diagnostics coming from the compiler).<br>
>><br>
>> That seems fine for text output, but for other clients (e.g., IDEs) we have diagnostic categories that could provide the same functionality with a much better experience.<br>
><br>
> True, no ideas how to do that though. Distinguishing between "compile error because the code is wrong" and "compile error because of a #error" is at least reasonably important I think.<br>
<br>
</div>But the caret location makes it blindingly obvious that this came from a #error or #warning. We don't need the diagnostic text to remind us a second time.</blockquote><div><br></div><div>Sure, but not everyone has the caret diagnostics turned on. </div></div></blockquote><div><br></div><div>They're not getting the full benefit of Clang's diagnostics, and they'll have far bigger problems than deciding whether Clang generated the error the user code generated the error. For example, when we complain that a + b + c + d has a type error in +, they have no clue which + we're talking about (and that's by design).</div><br><blockquote type="cite"><div class="gmail_quote"><div>It seems nice to distinguish in the text where the actual text comes from. That said, it just seems nice-to-have, not super important.</div>
<div><br></div><div>Certainly "#error" seems like a pretty lame way to do this. ;] My initial thought would be:</div><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">
foo.cc:42:13: error: (from source directive) this code requires widget to be defined</blockquote><div>or some variant thereof.</div><div><br></div><div>Among other nice things is that then the message is the same between #error and #warning, and only the level changes. The downside I see is that it's more verbose. </div></div></blockquote><div><br></div><div>That's a step up from "#error", but I still find it unnecessary.</div><br><blockquote type="cite"><div class="gmail_quote"><div>Some (obvious) alternatives</div>
<div><br></div><div>foo.cc:42:13: error: source directive: ...</div><div>foo.cc:42:13: error: ... [directive]</div><div>foo.cc:42:13: error: ... [-Wdirective] (do we even have a flag for these?)</div><div><br></div><div>
Someone else can probably come up with a nicer way to phrase this than I can...</div></div>
</blockquote></div><div><br></div><div>I'm totally not digging the "-Wdirective"; it's too subtle.</div><br><div><span class="Apple-tab-span" style="white-space:pre"> </span>- Doug</div></body></html>