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><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></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><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>