[PATCH] Allow string literals as module identifiers

[Manuel Klimek]

On Thu, Oct 31, 2013 at 6:02 PM, Doug Gregor <dgregor at apple.com> wrote:

>   Sorry for the slow reply, but it seems like a net loss to generalize the
> simple identifier-based module naming scheme to full string literals,
> because we're making the mental model more complex ("when do I use / in a
> string literal vs. a submodule?"). The automatic mapping from header names
> to module names is a convenience that helps one avoid writing module maps
> for everything. When the automatic mapping "fails" because the header name
> isn't an identifier, I think it's reasonable to either (1) require that the
> user provide an identifier to name the (sub)module corresponding to that
> header, or (2) sanitize the name in some way to make it an identifier. In
> particular, I don't think it's important at all for the unmodified header
> name to be namable from an (@)import declaration, since one can continue
> using #include until a suitable name is chosen for the (sub)module.
>

I think the most interesting feature this would enable is to automatically
generate good diagnostics for layering violations when implicit modules are
used via the build system (we'd still #include everything in that case).
Imagine adding something to CMake that automatically generates module maps
for each cmake add_library call, including all the headers in the sources
of that library, thus speeding up incremental compiles without needing any
changes to the code if it already complies with the unwritten rules of sane
C++ code.

Of course we could map library names to C++ identifiers on the cmake level,
but then the diagnostics that mention modules (for example when pointing
out layering violations due to private headers) would have names with no
corresponding "real" entity, thus being confusing to users.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131104/095e43de/attachment.html>