[cfe-commits] r86001 - in /cfe/trunk: include/clang/Basic/DiagnosticSemaKinds.td lib/Sema/SemaDeclAttr.cpp test/Sema/callingconv.c test/Sema/stdcall-fastcall.c
rjmccall at apple.com
Wed Nov 4 16:30:31 PST 2009
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.
>> ...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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-commits