<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Aug 29, 2013, at 11:32 AM, Reid Kleckner wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">I think the lesson of CC_Default vs. CC_C is that there are *far* too many places to check for calling convention compatibility, and that it's much better to use a single representation for equivalent conventions.<div>
<br></div><div>Therefore, I'd remove areCCsCompatible() and let TargetInfo::checkCallingConvention() adjust the the sysv or MS CCs to CC_C when appropriate.</div><div><br></div><div>This way, when you target x64 Windows, the ms_abi attr will show up in the AST, but it will produce function types that are nicely canonically equivalent to normal function types. Similarly, sysv_abi will be a no-op on sysv targets.</div></div></blockquote>You mean, like this?</div><div><br></div><div>There's one side effect of your suggested change that still bugs me, though. Now, if we're on a target that uses the SysV calling convention, the diagnostics always say "cdecl", even if the function was explicitly declared "sysv_abi". (Same with Windows and "ms_abi".) This might be slightly confusing to your average user, but for obvious reasons I don't want to add special cases to the places these diagnostics get printed.</div><div><br></div><div>Chip</div><div></div></body></html>