<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 15/10/15 01:12, Richard Smith wrote:<br>
</div>
<blockquote
cite="mid:CAOfiQqkNUTNzzuywTo1tALWV4qgVMp8b5J78gZQVsNGHwwOtnw@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">On Wed, Oct 14, 2015 at 1:31 AM,
Vassil Vassilev <span dir="ltr"><<a
moz-do-not-send="true" href="mailto:vvasilev@cern.ch"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:vvasilev@cern.ch">vvasilev@cern.ch</a></a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><span class="">
<div>On 12/10/15 21:13, Richard Smith via cfe-dev
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">On Mon, Oct 12, 2015 at
11:33 AM, Serge Pavlov via cfe-dev <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:cfe-dev@lists.llvm.org"
target="_blank">cfe-dev@lists.llvm.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px
#ccc solid;padding-left:1ex">
<div dir="ltr">
<div>Hi all,</div>
<div><br>
</div>
<div>Now building a module involves
creation of intermediate source streams
that includes/imports each header
composing the module. This source
stream is then parsed as if it were a
source file. So to build a module
several transformations must be done:</div>
<div>- Module map is parsed to produce
module objects(clang::Module),</div>
<div>- Module objects are used to build
source stream (llvm::MemoryBuffer),
which contains include directives,</div>
<div>- The source stream is parsed to
produce module content.</div>
<div><br>
</div>
<div>The build process could be simpler,
if instead of text source stream we
prepared a sequence of annotation
tokens, annot_module_begin,
annot_module_end and some new token, say
annot_module_header, which represented a
header of a module. It would be
something like pretokenized header but
without a counterpart in file system.</div>
<div><br>
</div>
<div>Such redesign would help in solving
performance degradation reported in
PR24667 ([Regression] Quadratic module
build time due to
Preprocessor::LeaveSubmodule). The
reason of the problem is leaving module
after each header, even if the next
header is of the same module.</div>
</div>
</blockquote>
<div><br>
</div>
<div>We generally recommend that each header
goes in its own submodule, so optimizing for
this case doesn't address the problem for a
lot of cases.</div>
</div>
</div>
</div>
</blockquote>
</span> Is there a technical reason for this? Is there a
difference (say bigger module size or slower
deserialization) between a header file per submodule and
a hearder file per standalone module?<br>
</div>
</blockquote>
<div><br>
</div>
<div>The technical reason is that it gives more precise
control over name export / import -- that is, if you don't
do this then #including a modular header file can make too
many names visible, and if you develop using that approach
then your builds will likely fail due to use of undeclared
names when you build without modules enabled.</div>
</div>
</div>
</div>
</blockquote>
Got it, thanks.<br>
<blockquote
cite="mid:CAOfiQqkNUTNzzuywTo1tALWV4qgVMp8b5J78gZQVsNGHwwOtnw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> We stumble upon
(see attachment) cases which compile just fine without
modules and with standalone modules (i.e. header per
module). They do not compile with the submodule model.<br>
</div>
</blockquote>
<div><br>
</div>
<div>That's somewhat separate from what we're talking about;
this also doesn't compile with the "all the headers in the
same module with no submodules" approach. The problem here
is that you're violating [basic.scope.declarative]p4, so
your program is ill-formed, and with modules enabled Clang
is able to detect and diagnose this. (I'm inclined to
permit your example -- we should only really be diagnosing
redeclaration conflicts between entities if either both
have linkage or the old declaration is visible -- and if
we did so then the one-submodule-per-header approach would
work and the one-big-module approach would fail for your
testcase.)</div>
</div>
</div>
</div>
</blockquote>
Yes it doesn't compile with "all the headers in the same module with
no submodules". It compiles just fine with standalone modules
(commenting out module Top in the example).<br>
<br>
I am totally for allowing this to work. It will make the migration
to modules in our case (maybe not only?) *a lot* easier. Could I
help addressing this issue and where should I start from?<br>
<br>
Vassil<br>
</body>
</html>