[PATCH] D26267: [Modules] Include builtins with #include instead of #import for ObjC
Richard Smith via cfe-commits
cfe-commits at lists.llvm.org
Wed Nov 30 11:34:36 PST 2016
On 30 November 2016 at 11:08, Bruno Cardoso Lopes via Phabricator via
cfe-commits <cfe-commits at lists.llvm.org> wrote:
> > I suspect the problem is instead that #import just doesn't work properly
> with modules
>
> (specifically, either with local submodule visibility or with modules
> that do not export *),
> > because it doesn't care whether the previous inclusion is visible or
> not, and as a result it assumes
> > "I've heard about someone #including this ever" means the same thing as
> "the contents of this file
> > are visible right now". I know that #pragma once has this issue, so I'd
> expect #import to also suffer from it.
>
> Taking a look at this, any ideas on what's the right approach with the
> #import's here? So instead of entering the header, is there a way to make
> the contents for the module matching the built-in header to become
> available/visible at that point?
The right thing to do would be to track the set of headers whose #import /
#include-with-#pragma-once is visible, and only skip inclusions if there is
a *visible* #import / #include-with-#pragma-once of that header. (Much like
we only skip an include due to an include guard if there is a visible
definition of the include guard macro.) For instance, instead of a single
`isImport` bit on `HeaderFileInfo`, we could store a list of IDs of
submodules that have imported the header, and check whether any of those
are visible when deciding whether to skip an inclusion, but there's
probably a cheaper way (in common cases) to get the same effect.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20161130/5c6ef70f/attachment.html>
More information about the cfe-commits
mailing list