<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Mar 16, 2013, at 3:54 PM, Richard Smith <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">On Sat, Mar 16, 2013 at 10:32 AM, Argyrios Kyrtzidis <span dir="ltr"><<a href="mailto:akyrtzi@gmail.com" target="_blank">akyrtzi@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div>On Mar 16, 2013, at 10:18 AM, David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:<br>
<br>
> On Sat, Mar 16, 2013 at 10:13 AM, Dmitri Gribenko <<a href="mailto:gribozavr@gmail.com" target="_blank">gribozavr@gmail.com</a>> wrote:<br>
>> On Sat, Mar 16, 2013 at 3:40 AM, Argyrios Kyrtzidis <<a href="mailto:akyrtzi@gmail.com" target="_blank">akyrtzi@gmail.com</a>> wrote:<br>
>>> Author: akirtzidis<br>
>>> Date: Fri Mar 15 20:40:35 2013<br>
>>> New Revision: 177218<br>
>>><br>
>>> URL: <a href="http://llvm.org/viewvc/llvm-project?rev=177218&view=rev" target="_blank">http://llvm.org/viewvc/llvm-project?rev=177218&view=rev</a><br>
>>> Log:<br>
>>> Remove -Wspellcheck and replace it with a diagnostic option.<br>
>>><br>
>>> Thanks to Richard S. for pointing out that the warning would show up<br>
>>> with -Weverything.<br>
>><br>
>> If we are going to start testing clang this way, it would be better to<br>
>> design this first, so that adding new 'testing' diagnostics is easy<br>
>> *and* does not slow down the normal compilation.  I think the second<br>
>> part is addressed already.<br>
>><br>
>> For example, adding a command line option every time is excessive.<br>
>> This option could be renamed to -fclang-debugging-diagnostics, and all<br>
>> such diagnostics could be placed under a special flag<br>
>> -Wclang-debugging.<br>
><br>
> I still don't understand the need for this at all. At a glance it<br>
> seems like we're adding a positive diagnostic so we can check for the<br>
> absence of a diagnostic - but we've never had a need to do this in the<br>
> past. "-verify" fails if a diagnostic is emitted where it isn't<br>
> expected so the absence of expected-blah lines is sufficient to test<br>
> that we don't emit a diagnostic.<br>
><br>
> Am I missing something here? Why are we doing this?<br>
<br>
</div>This code snippet of an objc method<br>
<br>
-(void)objc_method: {<br>
  super.x = 0;<br>
}<br>
<br>
would trigger typo-correction for 'super' silently, without emitting any diagnostic.<br>
For the regression test I added I put:<br>
<br>
typedef int super1;<br>
<br>
so typo-correction "succeeds" in correcting 'super' to 'super1' and errors are emitted.<br>
For regression testing purposes this would be sufficient though I don't like that we would be inferring that a typo-correction did not trigger indirectly (it is possible, though unlikely, that typo-correction would trigger without resolving to the intended identifier)<br>

</blockquote><div><br></div><div>The way we usually handle this is with both a positive and a negative test:</div><div><br></div><div>struct X { int x; } super1;</div><div>-(void)objc_method: {<br>  super.x = 0; // expected-no-error<br>

}<br></div><div>void c_function() {</div><div>  super.x = 0; // expected-error {{did you mean 'super1'}}</div><div>}</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


Beyond regression testing I'd like to have a way to get notified when typo-correction is silently triggered for general testing.</blockquote><div><br></div><div>I'm not convinced that this has sufficient value to justify adding a -cc1 option for it. Can you elaborate on why this is important?</div></div></blockquote><div><br></div><div>I'm not sure what else I could say beyond repeating myself; typo-correction is expensive, triggering it needlessly is unacceptable, a -cc1 option allows making sure that it is not triggered across full project sources.</div><div>I don't see much complexity or maintenance involved for justifying not having it.</div><div><br></div><blockquote type="cite"><div class="gmail_quote">

<div><br></div><div>I'm also surprised we hit the typo-correction codepath at all in this case; we shouldn't be getting there unless we've already decided to emit a diagnostic.</div></div>
</blockquote></div><br></body></html>