[cfe-commits] [PATCH] #import directive in MS compatibility mode

J B jayblanchard.cpp at gmail.com
Wed Mar 14 21:25:35 PDT 2012

The reason I recommend an error is because the code will error out later
without the .tlh (where it is requested via attributes or absence of).  The
errors later will be a direct result of the failure of #import to function

If we try to auto-include, where would we look for the files?  Apparently
it will be given the same timestamp as the type library itself, as one way
to verify the files are correctly matched, but you'll have to replicate the
type lib search pattern (which can be progid-based and other odd lookup
systems that will hit the registry).  Could be ugly.

Jay Blanchard

On Thu, Mar 15, 2012 at 12:07 AM, Aaron Ballman <aaron at aaronballman.com>wrote:

> On Wed, Mar 14, 2012 at 10:52 PM, J B <jayblanchard.cpp at gmail.com> wrote:
> > MSVC typically throws the generated .tlh (type library header) and .tli
> > (wrapper implementation) into the solution's defined intermediate
> > directory.  They aren't part of the source tree unless someone explicitly
> > makes them part of the source tree.
> >
> > It might make sense to error on #import with information to generate the
> > files with MSVC and make them permanent, and switch to #includes.
> >
> > I believe the attributes can be ignored unless you're going to go forward
> > with this auto-determined include plan.  If you do that, you'll need to
> pay
> > attention to the attributes implementation_only and no_implementation, as
> > they control whether there is a .tlh or .tli
> More and more I'm liking the original idea of warning the user that
> #import will not work for them and not including the binary file.
> However, I think I do still need to parse the attribute stuff (to
> ignore) for no other reason than so that the parser doesn't barf on
> the rest of the file.
> We can always revisit at a later date if we decide we want to try to
> be more constructive or creative.
> Any objections?
> ~Aaron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120315/004b8af4/attachment.html>

More information about the cfe-commits mailing list