[cfe-commits] r107264 - in /cfe/trunk: lib/CodeGen/MicrosoftCXXABI.cpp test/CodeGenCXX/mangle-ms.cpp

[Charles Davis]

On Jun 30, 2010, at 9:42 AM, Douglas Gregor wrote:

> 
> On Jun 30, 2010, at 1:09 AM, Charles Davis wrote:
> 
>> Author: cdavis
>> Date: Wed Jun 30 03:09:57 2010
>> New Revision: 107264
>> 
>> URL: http://llvm.org/viewvc/llvm-project?rev=107264&view=rev
>> Log:
>> Mangle arrays in the Microsoft C++ Mangler. It's not quite finished (it
>> doesn't mangle array parameters right), but I think that should be fixed
>> in Sema (Doug, John, what do you think?).
> 
> I assume that you're referring to this example...
> 
>> +// Array mangling. (It should be mangled as a const pointer, but that needs
>> +// to be fixed in Sema.)
>> +void epsilon(int a[][10][20]) {}
>> +// CHECK: @"\01?epsilon@@YAXPAY19BD at H@Z"
This demangles to "void __cdecl epsilon(int (*)[10][19]);" (The \01 is so the emitted name in the assembly/object file has no leading underscore or leading/trailing @ signs. Also, notice how the second dimension isn't quite right. I need to fix that...)
> 
> 
> But I'm not quite certain what that mangled name means for MSVC. From the language perspective, epsilon's parameter is of type int (*)[10][20], because the array parameter decays to a pointer. Does MSVC perform some other transformation on the parameter type? Is that something we have to model under -fms-extensions?
The problem is that MSVC itself mangles the function as:
  ?epsilon@@YAXQAY19BE at H@Z
which demangles to "void __cdecl epsilon(int (* const)[10][20]);". In general, MSVC mangles parameter arrays as const pointers. (There's a comment at the top of MicrosoftCXXNameMangler::mangleType(ArrayType*) that explains this.) To mangle it properly, either I need to know that the parameter was declared as an array or the type system needs to think it's a const pointer. I now realize that the second way is wrong (MSVC lets you assign to an array parameter), but the problem is that by the time the FunctionType is built the information about whether the parameter was an array or pointer is lost. So I was thinking that it would be easier to just say the parameter is a const pointer--which, again, is wrong even with -fms-extensions.

The "proper" way IMO is to store it in the FunctionType's argument list as an IncompleteArrayType and have canonicalization of the function type decay it to a pointer. Then the mangler will detect that it's mangling a parameter array and mangle it as a const pointer. At least, there really should be some way of detecting that a parameter was declared as an array instead of a pointer.

Chip