[PATCH] Add stopgap option -fmodule-implementation-of

[Richard Smith]

On Tue, May 27, 2014 at 8:31 AM, Ben Langmuir <blangmuir at apple.com> wrote:

> CC’ing djasper, since you made -fmodule-name a driver option, so you may
> be familiar with this code.
>
> I’m not super happy with this patch, but we really need some way to not
> use modular imports while compiling the implementation (e.g. .c/.cpp/.m
> files) files that correspond to module headers.  Both because we are not
> yet isolating submodules from each other enough to do incremental rebuilding


Can you explain what you mean by this? In particular, I'm very unclear on
how it the translation unit being compiled has any relation to this issue.
(I've not seen any problems that match this description so far.)

and because with the VFS added to the mix we may get a mix of textual and
> modular imports of the same headers when doing “quote”-style includes,
> which doesn’t yet work properly (multiple definitions, hidden definitions,
> fun stuff).
>

I assume you intend for this bug to be fixed eventually. Once that's done,
is there still value in this flag?


>     Add stopgap option -fmodule-implementation-of <name>
>

Please do not add a stopgap workaround to our stable and
backwards-compatible driver interface; just add it to -cc1 instead.

    This flag specifies that we are building an implementation file of the
>     module <name>, preventing importing <name> as a module. This does not
>     consider this to be the 'current module' for the purposes of doing
>     modular checks like decluse or non-modular-include warnings, unlike
>     -fmodule-name.


I don't see any relation between the flag's name and its functionality;
there seems to be no reason for this to be linked to the translation unit
being the implementation of any particular module (and if there were,
that's what -fmodule-name is for). Instead, I think what you're trying to
specify is that a particular module is included textually for this
compilation. Please pick a name that suggests that functionality instead.

I'm also not sure how this is supposed to work in general: suppose the
implementation of module A imports module B, and module B includes a header
from module A. Do we get another variant of module B, or do we textually
include A into B (generating probably-broken submodule visibility), or is
that now an error, or something else?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140527/d3cde9f2/attachment.html>