I would make a small example app using all of these
constructs and see how MSVC handles mangling them and compare that to
what clang currently emits
I tested CodeGenCXX folder with MSVC and Clang. Some stats:
464 tests, 63 assertion failures, 5 crash dumps, around 80 tests have a mangling mismatches against VC++.
Of course, some of mismatches is a check script failures, but whole state of the situation
(in context of windows support) looks sadly.
x64 mode: http://bit.ly/W2hBal
x86 mode: http://bit.ly/W2hFqM
(1st line is demangled name, 2nd is mangled by VC, 3rd is by Clang)
I would focus on function parameters (public, protected, private and
non-instance), and then return types first. Then I'd focus on global
Posted at Phabricator.
Nice, I’ve wanted to make a script for a while to compare both but never got around to it. If you’re willing to share it, maybe we could add it to the repo and maybe even run it as part of the test suite under MSVC mode?
Many failures seem related to RTTI base class descriptors, which are expected. r4start has implemented that in his repo, so when we pull that into Clang those should get fixed. Another big one seem to be anonymous namespaces.
I think the situation on x86 is gradually improving on the "as needed"
basis, at least I can build substantial parts of Chromium with Clang.
If you have any particular cases which are really blockers and they
seem easy to fix, please file bugs and provide test cases.
Ideally, "a real blocker" is when link.exe prints out an "undefined
symbol" error when you try to link Clang-built obj with a CL-built
In this case, it's obvious that we're doing something wrong and it's
obvious what we should do instead.
If you can't provide such a test case - well, it might not be that important
The only exception is probably RTTI as is basically not supported with
"-cxx-abi microsoft" at the moment and it's doesn't add much value to
file RTTI-mangling bugs for a neither supported nor planned feature.