<div><div class="gmail_extra"><div class="gmail_quote">On 19 Sep 2016 6:53 pm, "Manman via cfe-commits" <<a href="mailto:cfe-commits@lists.llvm.org" target="_blank">cfe-commits@lists.llvm.org</a>> wrote:<br type="attribution"><blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div><div></div><div><br></div><div><br>On Sep 19, 2016, at 5:55 PM, Richard Smith via cfe-commits <<a href="mailto:cfe-commits@lists.llvm.org" target="_blank">cfe-commits@lists.llvm.org</a>> wrote:<br><br></div><blockquote type="cite"><div><div>Your c.h is not correct. It would introduce a definition of c in every file where it's included, so it's not a modular header.<br></div></div></blockquote></div><div>Hi Richard,</div><div><br></div>What do you mean by c.h is not correct? It is guarded by a macro, so if we are not using modules, it will work.</div></blockquote></div></div></div><div><br></div><div>It will not work (due to multiple definition errors) if it's included into two source files anywhere in the entire program.</div><div><br></div><div>If it's only intended to be included into a single source file in the entire program, there's no point in putting it in a module.</div><div><br></div><div><div class="gmail_extra"><div class="gmail_quote"><blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>Also I thought the definition of a non-modular header is that it is not mapped to any module. Is that my misunderstanding? Is there a formal definition for modular header?</div></div></blockquote></div></div></div><div><br></div><div>I'm not sure if we have this written down anywhere, but it's something like: a header that is self contained, does not intended to depend on the compilation state at its point of inclusion, and has no effect other than making some set of declarations and macros visible.</div><div><br></div><div><div class="gmail_extra"><div class="gmail_quote"><blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>Thanks,</div><div>Manman<div><br><blockquote type="cite"><div><div><div class="gmail_extra"><br><div class="gmail_quote">On 19 Sep 2016 5:21 pm, "Manman via cfe-commits" <<a href="mailto:cfe-commits@lists.llvm.org" target="_blank">cfe-commits@lists.llvm.org</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Hi Richard & Ben,<br>
<br>
Given a simple testing case, where we have two submodules X.A (A.h) and X.B (B.h, it includes C.h, and C.h is guarded with a macro), when we import X.A and then textually include a header C.h, we get redefinition error. This is because the macro guard is owned by module X.B that is not yet visible. I wonder what the fix is if this is considered a compiler issue. We can:<br>
1> do not emit the redefinition error if the earlier definition is not visible, or<br>
2> emit diagnostics to suggest user to import the whole module, when redefinition happens because the module includes a non-modular header and the non-modular header is also textually included, or<br>
3> other suggestions?<br>
<br>
Note that if we textually include C.h, then import X.A, there are no compiler errors.<br>
<br>
The testing case here:<br>
clang -cc1 repro.c -fsyntax-only -I Inputs4/ -fmodules -fimplicit-module-maps -fmodules-cache-path=tmp<br>
cat repro.c<br>
#include "A.h" //modular header<br>
#include "C.h" //non-modular header<br>
<br>
cat Inputs4/module.map<br>
module X {<br>
module A {<br>
header "A.h"<br>
export *<br>
}<br>
module B {<br>
header "B.h"<br>
export *<br>
}<br>
export *<br>
}<br>
cat Inputs4/A.h<br>
#ifndef __A_h__<br>
#define __A_h__<br>
#endif<br>
cat Inputs4/B.h<br>
#ifndef __B_h__<br>
#define __B_h__<br>
#include "C.h"<br>
#endif<br>
cat Inputs4/C.h<br>
#ifndef __C_h__<br>
#define __C_h__<br>
int c = 1;<br>
const int d = 2;<br>
#endif<br>
<br>
Thanks,<br>
Manman<br>
______________________________<wbr>_________________<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/<wbr>mailman/listinfo/cfe-commits</a><br>
</blockquote></div></div>
</div>
</div></blockquote><blockquote type="cite"><div><span>______________________________<wbr>_________________</span><br><span>cfe-commits mailing list</span><br><span><a href="mailto:cfe-commits@lists.llvm.org" target="_blank">cfe-commits@lists.llvm.org</a></span><br><span><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-commits</a></span><br></div></blockquote></div></div></div><br>______________________________<wbr>_________________<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/<wbr>mailman/listinfo/cfe-commits</a><br>
<br></blockquote></div><br></div></div>