<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Apr 18, 2016 at 11:49 AM, Vassil Vassilev <span dir="ltr"><<a href="mailto:v.g.vassilev@gmail.com" target="_blank">v.g.vassilev@gmail.com</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"><div><div class="h5">
<div>On 18/04/16 20:32, Richard Smith wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">On Mon, Apr 18, 2016 at 6:28 AM,
Vassil Vassilev <span dir="ltr"><<a href="mailto:v.g.vassilev@gmail.com" target="_blank"></a><a href="mailto:v.g.vassilev@gmail.com" target="_blank">v.g.vassilev@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>On 08/04/16 03:24, Richard Smith via
cfe-commits wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Author:
rsmith<br>
Date: Thu Apr 7 20:23:59 2016<br>
New Revision: 265766<br>
<br>
URL: <a href="http://llvm.org/viewvc/llvm-project?rev=265766&view=rev" rel="noreferrer" target="_blank">http://llvm.org/viewvc/llvm-project?rev=265766&view=rev</a><br>
Log:<br>
[modules] Add a comment to explain why -E leaves some
#includes in the preprocessed output.<br>
<br>
Modified:<br>
cfe/trunk/lib/Frontend/PrintPreprocessedOutput.cpp<br>
cfe/trunk/test/Modules/preprocess.cpp<br>
<br>
Modified:
cfe/trunk/lib/Frontend/PrintPreprocessedOutput.cpp<br>
URL: <a href="http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/PrintPreprocessedOutput.cpp?rev=265766&r1=265765&r2=265766&view=diff" rel="noreferrer" target="_blank">http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/PrintPreprocessedOutput.cpp?rev=265766&r1=265765&r2=265766&view=diff</a><br>
==============================================================================<br>
--- cfe/trunk/lib/Frontend/PrintPreprocessedOutput.cpp
(original)<br>
+++ cfe/trunk/lib/Frontend/PrintPreprocessedOutput.cpp
Thu Apr 7 20:23:59 2016<br>
@@ -336,7 +336,9 @@ void
PrintPPOutputPPCallbacks::Inclusion<br>
OS << "#include "<br>
<< (IsAngled ? '<' : '"')<br>
<< FileName<br>
- << (IsAngled ? '>' : '"');<br>
+ << (IsAngled ? '>' : '"')<br>
+ << " /* clang -E: implicit import for
module "<br>
+ << Imported->getFullModuleName()
<< " */";<br>
</blockquote>
</span>
It seems that in some cases the FileName needs to be
tweaked to be able to compile the output back. For
instance:<br>
clang -I folder/ file.cxx<br>
cat file.cxx<br>
#include "subfolder/A.h"<br>
<br>
cat folder/subfolder/A.h<br>
#include "B.h"<br>
<br>
B.h resides in folder/subfolder/ and FileName argument
would be B.h causing the printer to generate #include
"B.h" /* clang -E: implicit import for... */ which cannot
be compiled back.</blockquote>
<div><br>
</div>
<div>Ugh, yeah, that makes sense.</div>
<div><br>
</div>
<div>It seems superficially that what we should do for a
file found relative to the current file (or in MSVC mode,
for a file found relative to a possibly-indirect includer
of the current file) is to prepend the path from that
file's search path to the current file. That is, if we
find "foo/bar.h" in search path "includes/x", and we find
"baz/quux.h" relative to bar.h, we should produce the path
"foo/baz/quux.h" (to be found relative to "includes/x").
However, that won't work if there is a prior include path
that also contains a "foo/baz/quux.h", so we would need to
also include the search path in the include path. And
*that* won't work if . is not a search path and one of the
search paths is a relative path.</div>
</div>
</div>
</div>
</blockquote></div></div>
:( at first looked like an easy, nice solution, but apparently "twin
peaks" killer phase is true again :)<span class=""><br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>I wonder whether the problem is really that we're
handling #include search paths incorrectly in the presence
of #line markers.</div>
</div>
</div>
</div>
</blockquote></span>
I am not sure I understand this. Could you give an example?</div></blockquote><div><br></div><div>Suppose we have:</div><div><br></div><div>foo/bar.h:</div><div>#include "baz.h"</div><div><br></div><div>foo/baz.h:</div><div>// ...</div><div><br></div><div>foo/module.modulemap</div><div>textual header "bar.h"</div><div>module Baz { header "baz.h" } </div><div><br></div><div>foo.cc:</div><div>#include "foo/bar.h"</div><div><br></div><div>We currently produce a preprocessed source file like this:</div><div><br></div><div># 1 "foo/bar.h"</div><div>#include "baz.h"</div><div><br></div><div>This is, in some sense, "correct" -- the #include line from "foo/bar.h" did say "baz.h". But we'll look for "baz.h" relative to the current preprocessed source file, not relative to "foo/bar.h".</div><div><br></div><div>We could change the preprocessor so that in the above case it searches relative to "foo/" instead, but that will break a collection of other use cases (and is different from GCC's behavior, and breaks the common flow of deleting the #line markers when reducing a test case, and so on). So instead, we could provide a modified syntax for the above that requests that the #include of "baz.h" be found relative to "foo/bar.h". We would only need to do this in the narrow case that (a) the include names a module header, and (b) that module header was found relative to the including file, and (c) the including file was itself included into the main source file.</div><div><br></div><div>Another alternative would be to provide a module import keyword that works across languages. Given that the C++ Modules TS is making good progress, perhaps we can just ignore this problem for now (this change is at least not a regression) and solve it by generating an import once we implement the real syntax.</div><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"><span class=""><br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> Perhaps for the relative path search we should somehow
instruct clang to look for files relative to the presumed
file rather than the physical file?</div>
</div>
</div>
</div>
</blockquote></span>
Could we detect that we are compiling a preprocessed file? I guess
there are traces, eg. include stack push/pop values...<div><div class="h5"><br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> That would match our intent for these files. However,
this doesn't match the GCC behavior, so we probably can't
do it by default. =/</div>
</div>
</div>
</div>
</blockquote>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div>
<div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
}<br>
// Since we want a newline after the @import,
but not a #<line>, start a new<br>
// line immediately.<br>
<br>
Modified: cfe/trunk/test/Modules/preprocess.cpp<br>
URL: <a href="http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/preprocess.cpp?rev=265766&r1=265765&r2=265766&view=diff" rel="noreferrer" target="_blank">http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/preprocess.cpp?rev=265766&r1=265765&r2=265766&view=diff</a><br>
==============================================================================<br>
--- cfe/trunk/test/Modules/preprocess.cpp (original)<br>
+++ cfe/trunk/test/Modules/preprocess.cpp Thu Apr 7
20:23:59 2016<br>
@@ -1,6 +1,6 @@<br>
// RUN: rm -rf %t<br>
// RUN: %clang_cc1 -fmodules
-fimplicit-module-maps -fmodules-cache-path=%t -I
%S/Inputs -x c++ -E %s | \<br>
-// RUN: FileCheck -strict-whitespace %s
--check-prefix=CHECK --check-prefix=CXX<br>
+// RUN: FileCheck -strict-whitespace %s
--check-prefix=CHECK --check-prefix=CXX
--check-prefix=CXX-DASHE<br>
// RUN: %clang_cc1 -fmodules
-fimplicit-module-maps -fmodules-cache-path=%t -I
%S/Inputs -x objective-c -E %s | \<br>
// RUN: FileCheck -strict-whitespace %s
--check-prefix=CHECK --check-prefix=OBJC<br>
// RUN: %clang_cc1 -fmodules
-fimplicit-module-maps -fmodules-cache-path=%t -I
%S/Inputs -x c++ -E -frewrite-includes %s | \<br>
@@ -14,7 +14,9 @@ foo bar baz<br>
// The weird {{ }} here is to prevent the
-frewrite-includes test from matching its own CHECK
lines.<br>
// CXX: #include{{ }}"dummy.h"<br>
+// CXX-DASHE-SAME: /* clang -E: implicit import for
module dummy */<br>
// CXX: #include{{ }}"dummy.h"<br>
+// CXX-DASHE-SAME: /* clang -E: implicit import for
module dummy */<br>
// CXX: foo bar baz<br>
// OBJC: @import{{ }}dummy; /* clang<br>
<br>
<br>
_______________________________________________<br>
cfe-commits mailing list<br>
<a href="mailto:cfe-commits@lists.llvm.org" target="_blank">cfe-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits</a><br>
</blockquote>
<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<br>
</div></div></div>
</blockquote></div><br></div></div>