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.
On 19 Sep 2016 5:21 pm, "Manman via cfe-commits" <cfe-commits@lists.llvm.org>
wrote:
>
> Hi Richard & Ben,
>
> 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:
> 1> do not emit the redefinition error if the earlier definition is not
> visible, or
> 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
> 3> other suggestions?
>
> Note that if we textually include C.h, then import X.A, there are no
> compiler errors.
>
> The testing case here:
> clang -cc1 repro.c -fsyntax-only -I Inputs4/ -fmodules
> -fimplicit-module-maps -fmodules-cache-path=tmp
> cat repro.c
> #include "A.h" //modular header
> #include "C.h" //non-modular header
>
> cat Inputs4/module.map
> module X {
> module A {
> header "A.h"
> export *
> }
> module B {
> header "B.h"
> export *
> }
> export *
> }
> cat Inputs4/A.h
> #ifndef __A_h__
> #define __A_h__
> #endif
> cat Inputs4/B.h
> #ifndef __B_h__
> #define __B_h__
> #include "C.h"
> #endif
> cat Inputs4/C.h
> #ifndef __C_h__
> #define __C_h__
> int c = 1;
> const int d = 2;
> #endif
>
> Thanks,
> Manman
> _______________________________________________
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
