On Wed, Mar 14, 2012 at 6:02 PM, Francois Pichet <[email protected]> wrote: > On Wed, Mar 14, 2012 at 12:15 PM, Douglas Gregor <[email protected]> wrote: >> >> On Mar 12, 2012, at 4:10 PM, Aaron Ballman wrote: >> >>> MSVC uses the #import directive in a far different way than the >>> language extension clang supports. Instead of including the target >>> into the source, it parses a type library and generates C++ classes >>> from the definitions. This difference in behavior is large enough >>> that we should be warning users in MS compatibility mode so they can >>> understand what's happening. >>> >>> This patch addresses PR 10727. >> >> >> Given that the subject of an MSVC-style #import is likely to be a binary >> file, I think it would be better to simply warn that we are ignoring the >> #import directly entirely, rather than going through HandleIncludeDirective. >> Also, can you perhaps make > > Actually, MSVC #import will generate 2 header files from the typelib > and then include them. I think generating *.h from COM typelib is > outside the scope of clang but we could somehow assume that the .h are > already pregenerated and try to include them. > > That would make it possible to compile a COM project with clang if the > project has already been compiled with MSVC first. (to get the .h > generated).
Just so I can be sure I follow what you mean: When we see #import in MS mode, instead of importing the file specified (which is likely to be binary), we should attempt to import the primary header file (the TLH) which would have been generated by MSVC if it's available? What about all the attribute jazz? We're not currently parsing that; should we have a separate patch to parse and ignore it? ~Aaron _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
