[cfe-commits] r86001 - in /cfe/trunk: include/clang/Basic/DiagnosticSemaKinds.td lib/Sema/SemaDeclAttr.cpp test/Sema/callingconv.c test/Sema/stdcall-fastcall.c

[John McCall]

Daniel Dunbar wrote:
> On Wed, Nov 4, 2009 at 2:08 PM, John McCall <rjmccall at apple.com> wrote:
>   
>> Daniel Dunbar wrote:
>>
>> On Tue, Nov 3, 2009 at 7:36 PM, John McCall <rjmccall at apple.com> wrote:
>>
>>
>> +def err_cconv_knr : Error<
>> +  "function with no prototype cannot use '%0' calling convention">;
>>
>>
>> I'm not sure if we already have a canonical way of referring to this,
>> but IIRC we already use "K&R" in other places, which may be more
>> meaningful than "function with no prototype".
>>
>>
>> I disagree.  I think very few people know what K&R syntax is, outside of a
>> vague memory that they should (but usually don't) remember to write "(void)"
>> instead of "()" when declaring a nullary function.  ANSI C programmers
>> should at least be more familiar with the concept of a prototype.  The vast
>> majority of people encountering this error are going to be people who've
>> accidentally written their nullary function without void.
>>     
>
> I'm arguing more for normalizing the diagnostics than one particular
> spelling, I'm also not sure which one is best.
>   

Okay.

>> ...not that there's really any point to declaring a nullary function
>> fastcall, at least not in any of the conventions calling themselves
>> 'fastcall' that I know about.
>>     
>
> FWIW, this is also an argument that anyone who did this would not, in
> fact, have a nullary function.
>   

You'd be surprised;  a lot of novice programmers learn about calling 
conventions for the first time and start slapping 'fastcall' on 
everything, because obviously it makes things faster, right?

>> That said, maybe we should say "K&R" and just provide a fixit to put 'void'
>> in the argument list.
>>     
>
> We don't want to fixit things unless we know the fixit is correct,
> that wouldn't apply here.
>   

I have two responses to this.

The first is that we obviously wouldn't suggest this fixit on 
definitions with non-trivial K&R arguments.

The second is that I think this policy about fixits is both (1) 
misguided and (2) not really being followed with any consistency.  I 
mean, the parser has a fixit which inserts semicolons at the end of 
declarations;  there's no way that that's 100% correct, but it's still 
the most likely solution, so it's still really useful.  -Wparentheses 
has a fixit which inserts the parentheses;  that's useful because it 
tells the user how to suppress the diagnostic, but if we really think 
it's 100% correct, we shouldn't bother emitting the diagnostic in the 
first place.

The truth is that users should never blindly apply fixits, and any tool 
which lets them do so is probably really dangerous.  Once you accept 
that, fixits become just another axis of communication, suggesting the 
likely source of errors and how they might be resolved.

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20091104/ca524730/attachment.html>