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 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).
Add stopgap option -fmodule-implementation-of <name>
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.
This is needed as a stopgap until both of:
1) we can resolve relative includes to a VFS-mapped module (or can
safely import a header textually and as part of a module), and
2) we can safely do incremental rebuilding when implementation files
import submodules.
impl-of.patch
Description: Binary data
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
