[LLVMdev] Proposing a new 'alloca' parameter attribute to implement the Microsoft C++ ABI

[Stephen Lin]

> Quite the contrary, knowing that Clang's C++ ABI is completely
> incompatible with MS is a maintenance *simplification*.

Yes, for example, as explained by Bjarne once, incompatible name
mangling schemes for ABIs that are not guaranteed to be 100% binary
compatible is a _feature_, not a bug, since it prevents anyone from
even beginning to develop a workflow that relies upon linking possibly
incompatible binaries.

>
> Saying that supporting the MS C++ ABI is an uphill battle is an
> understatement (and better say MS C++ ABI*S*, because it evolved over
> time and it is known that it will change on future releases.) As far as
> I'm concerned, I'll never base my decisions on compiler usage on the
> advertisement of MS compatibility by Clang++, becase I *know* that for a
> very long time (maybe forever) whatever MS C++ libraries that work with
> Clang++ is by luck. That's what happens when you try to implement
> compatibility with an undocumented, propietary, complex feature.

This is my point as well; it just seems odd to spend so much effort to
implement and undocumented ABI with no guarantee of support or
stability (outside of MSVC major version releases). Furthermore, I
feel that, by reinforcing the notion that use of the MSVC++ ABI is
required for development on Windows (when no system-provided libraries
or ABIs require it), Clang developers are hindering the adoption of
Clang on Windows rather than promoting it, since it is unlikely that
any party that is not personally invested in Clang development would
be willing to depend on a backward engineered implementation of a
"required" but undocumented ABI for production use. Furthermore, it
means that Clang will always be behind the curve on Windows, since,
even if MSVC++ ABI support is fully usable one day, no one will be
willing to link it with object files from a new major version of MSVC
without some critical mass of users being guinea pigs first and
ensuring that there are no major bugaboos.

I agree that there is value in supporting implementing full MSVC++
ABI, if it can be done, but it seems like that support can never be
100% complete (or, more to the point, known to be 100% complete)
unless Microsoft itself decides to officially support the
implementation or completely stabilize and document their C++ ABIs.
However, I personally think that it is not only easier, there is more
value in implementing a C++ ABI which is compatible with officially
supported C and COM MSVC++ ABI subsets and consciously _not_
compatible in others way (in particular, which does not even attempt
to link C++ symbols with MSVC++, since that is not required for COM).
This is something that can be made to work and guaranteed (barring
some seriously misguided behavior from Microsoft) to continue to work
stably.

Furthermore, by providing and controlling its own Windows C++ ABI:
Clang can possibly offer something that MSVC *cannot* (and does not
even try to do): a development platform and ecosystem which provides a
stable-over-time C++ ABI and consistent cross-module usage of RTTI,
STL, C++ memory management, etc. (which is dicey even within MSVC
major versions unless the exact same build settings are used, last
time I checked.) This would give someone an active reason to switch to
Clang more than anything else Clang currently offers on Windows.

Stephen