[patch] Delay __fastcall attribute checking utnil after merging declarations

[Nico Weber]

On Tue, Aug 19, 2014 at 10:40 AM, Nico Weber <thakis at chromium.org> wrote:

> (adding back cfe-commits, which I had accidentally dropped.)
>
> On Thu, Jul 31, 2014 at 1:04 PM, Reid Kleckner <rnk at google.com> wrote:
>
>> On Thu, Jul 31, 2014 at 11:16 AM, Nico Weber <thakis at chromium.org> wrote:
>>
>>> On Thu, Jul 31, 2014 at 9:45 AM, Nico Weber <thakis at chromium.org> wrote:
>>>
>>>>  Thanks!
>>>>
>>>> On Tue, Jul 29, 2014 at 10:40 AM, Reid Kleckner <rnk at google.com> wrote:
>>>>
>>>>> +  // Diagnose the use of X86 fastcall on unprototyped functions.
>>>>>
>>>>> We should also diagnose unprototyped stdcall functions, but I'm not
>>>>> sure if that would be too disruptive.  Currently we accept this and always
>>>>> call _f at 0:
>>>>> void __stdcall f();
>>>>> int main() {
>>>>>   f(1);
>>>>>   f(1, 2);
>>>>>   f(1, 2, 3);
>>>>> }
>>>>>
>>>>> MSVC rejects with "t.c(5) : error C2708: 'f' : actual parameters
>>>>> length in bytes differs from previous call or reference".
>>>>>
>>>>
>>>> I added a TODO for adding this and reshuffled the if to make this easy
>>>> to add. I'll give it a try once this patch is in.
>>>>
>>>
>>>
>> Actually, should this happen for all isCalleeCleanup() calling
>>> conventions? I suppose thiscall always has a prototype, but pascal(l :-P)
>>> might not?
>>>
>>
>> That sounds like the right predicate, considering we verifier-fail on
>> this in plain C mode:
>> void __thiscall f();
>> int main() { f(1); }
>>
>> MSVC rejects __thiscall in C mode, but we don't.
>>
>
> I did give it a try, and rejecting stdcall fires on Windows SDK headers:
>
> ...win8sdk/Include/um\imm.h(432,13) :  error(clang): function with no
> prototype cannot use stdcall calling convention
> BOOL WINAPI ImmDisableLegacyIME();
>             ^
>

…but it looks like this is the only function that gets this wrong (at least
in a chromium build).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140819/e3899435/attachment.html>