[cfe-dev] Windows headers that are troublesome for clang

[Nico Weber]

On Tue, Aug 26, 2014 at 7:50 PM, James Gregurich <bayoubengal at mac.com>
wrote:

> ok. new topic is being started here...
>
> On Aug 26, 2014, at 5:46 PM, Reid Kleckner <rnk at google.com> wrote:
>
> > Your question isn't actually that clear. What kind of brokenness do you
> care about? Are you looking for C++ that clang can't parse, or standard
> library features that behave incompatibly on Windows?  I think you mean the
> former.
> >
> > The answer to that question is complicated. It depends on what you want
> to parse. I'd say there's several classes of stuff in order of increasing
> difficulty to parse:
> > - Plain C Windows SDK headers: windows.h
> > - MSVC C++ STL headers: vector, string
> > - Templateless COM headers: DirectX etc
> > - Template libraries: ATL, WRL
> >
> > The first three classes aren't that hard to parse. When they use
> standard language features, they are mostly well-formed. The difficulty in
> parsing them is that they use lots and lots of language extensions. The
> basic stuff is dllexport and __stdcall, but it gets harder. There are weird
> IDL attributes involving square brackets, for example.
> >
> > The final category is really something all on its own. MSVC's template
> model is drastically different from ours. You could hypothetically hack
> these headers in probably 20 or so places to get them to parse with Clang
> without any compatibility hacks, but you end up fighting an uphill battle.
> This is the category that native GUI apps tend to have, while batch
> processing apps like LLVM can get by with the first three sets.
>
> thanks for the response!
>
> I’m aware of difficulties in macro processing. that was mentioned by the
> boost fellow some time back.
>
>
> you are adding in a few more. Here is the list as I understand it. Please
> correct it if I am wrong.
>
> 1) problems with template definitions and instantiation
> 2) calling convention and export/import attributes.
> 3) IDL support
> 4) difficulties with macro definition and expansion.
>
>
> Have any of these been fully or partially addressed yet?
>

See http://llvm.org/bugs/show_bug.cgi?id=13707 and blockers, in particular
http://llvm.org/bugs/show_bug.cgi?id=12477 and blockers. Many of these
mention that they're for system headers, but not all the changes that were
necessary for system headers do say that. There's also a ton of work that
was done not tracked by bugs, search the commit logs for "ms abi" etc to
find that.


> a related question:
>
> as I understand it, if you run clang directly on windows (assuming a win32
> host environment verses as posix one (cygwin etc)), it compiles as it does
> on every other platform but the symbols will be gcc-style…not ms-style. If
> you run it with the clang-cl wrapper, it uses an alternative preprocessor
> that matches that of cl.exe. Is that understanding correct?


The clang-cl wrapper only sets different defaults. You can get the same
behavior with both the cl-compatible driver and the gcc-compatible driver
if you pass the right flags. You can pass -### to both drivers to see the
actual frontend flags they pass. The ABI is determined by the triple (the
driver's -target flag


> can one detect at compile time what processor he is going to get? Is there
> a switch to pick the desired preprocessor to override what clang-cl might
> choose by default?
>

Yes, see http://clang.llvm.org/docs/MSVCCompatibility.html


>
> -James
>
>
>
>
>
>
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140826/5d1fb4ce/attachment.html>