Bug 39206 - [Modules TS] Macro defined in module interface cannot be set in implementation

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug 39206 - [Modules TS] Macro defined in module interface cannot be set in implementation

David Blaikie via cfe-dev
This was discussed in a separate thread, but got lost in the discussion. 

I am currently working on porting a legacy project over to using the new modules-ts and would hit the issue linked in Bug 39206 I could not find any explicit section of the spec that says the processor should be effected by compilation of a module, however clang seems to be hiding macros that were defined in included header files that were also included in the interface module. 

If this is indeed a bug I would also appreciate help pointing in the right direction in the code. I have spent some time trying to find where the actual check is occurring that is hiding macros, but am at a loss.

Thanks,
Matt

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Bug 39206 - [Modules TS] Macro defined in module interface cannot be set in implementation

David Blaikie via cfe-dev
I believe there is an inherent issue with how clang uses the precompiled header structure to implement a module interface definition. When linking against this module file clang brings in all of the header lookup, which I can fix by forcing ModulesTS to not include the external source. However, it feels like I am fighting the pcm to ignore already included files and previously defined symbols that should have global module linkage. From reading the spec it feels like the pcm file should ONLY contain the symbols available from name lookup from module interface purview to implementation purview as well as exported symbols that are imported. 

Side note: As I try to track down these issues it seems odd that ModulesTS is forcing Modules to be turned on as well. Would it be easier to keep Clang Modules entirely separate from ModulesTS?

-Matt

On Sun, Oct 21, 2018 at 5:54 PM Matt Asplund <[hidden email]> wrote:
This was discussed in a separate thread, but got lost in the discussion. 

I am currently working on porting a legacy project over to using the new modules-ts and would hit the issue linked in Bug 39206 I could not find any explicit section of the spec that says the processor should be effected by compilation of a module, however clang seems to be hiding macros that were defined in included header files that were also included in the interface module. 

If this is indeed a bug I would also appreciate help pointing in the right direction in the code. I have spent some time trying to find where the actual check is occurring that is hiding macros, but am at a loss.

Thanks,
Matt

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Bug 39206 - [Modules TS] Macro defined in module interface cannot be set in implementation

David Blaikie via cfe-dev
[hidden email] Since you were discussing this with me before.

On Sun, Oct 21, 2018 at 7:08 PM Matt Asplund <[hidden email]> wrote:
I believe there is an inherent issue with how clang uses the precompiled header structure to implement a module interface definition. When linking against this module file clang brings in all of the header lookup, which I can fix by forcing ModulesTS to not include the external source. However, it feels like I am fighting the pcm to ignore already included files and previously defined symbols that should have global module linkage. From reading the spec it feels like the pcm file should ONLY contain the symbols available from name lookup from module interface purview to implementation purview as well as exported symbols that are imported. 

Side note: As I try to track down these issues it seems odd that ModulesTS is forcing Modules to be turned on as well. Would it be easier to keep Clang Modules entirely separate from ModulesTS?

-Matt

On Sun, Oct 21, 2018 at 5:54 PM Matt Asplund <[hidden email]> wrote:
This was discussed in a separate thread, but got lost in the discussion. 

I am currently working on porting a legacy project over to using the new modules-ts and would hit the issue linked in Bug 39206 I could not find any explicit section of the spec that says the processor should be effected by compilation of a module, however clang seems to be hiding macros that were defined in included header files that were also included in the interface module. 

If this is indeed a bug I would also appreciate help pointing in the right direction in the code. I have spent some time trying to find where the actual check is occurring that is hiding macros, but am at a loss.

Thanks,
Matt

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Bug 39206 - [Modules TS] Macro defined in module interface cannot be set in implementation

David Blaikie via cfe-dev
Thanks! followed up on the bug.

On Sun, Oct 21, 2018 at 7:09 PM Matt Asplund <[hidden email]> wrote:
[hidden email] Since you were discussing this with me before.

On Sun, Oct 21, 2018 at 7:08 PM Matt Asplund <[hidden email]> wrote:
I believe there is an inherent issue with how clang uses the precompiled header structure to implement a module interface definition. When linking against this module file clang brings in all of the header lookup, which I can fix by forcing ModulesTS to not include the external source. However, it feels like I am fighting the pcm to ignore already included files and previously defined symbols that should have global module linkage. From reading the spec it feels like the pcm file should ONLY contain the symbols available from name lookup from module interface purview to implementation purview as well as exported symbols that are imported. 

Side note: As I try to track down these issues it seems odd that ModulesTS is forcing Modules to be turned on as well. Would it be easier to keep Clang Modules entirely separate from ModulesTS?

-Matt

On Sun, Oct 21, 2018 at 5:54 PM Matt Asplund <[hidden email]> wrote:
This was discussed in a separate thread, but got lost in the discussion. 

I am currently working on porting a legacy project over to using the new modules-ts and would hit the issue linked in Bug 39206 I could not find any explicit section of the spec that says the processor should be effected by compilation of a module, however clang seems to be hiding macros that were defined in included header files that were also included in the interface module. 

If this is indeed a bug I would also appreciate help pointing in the right direction in the code. I have spent some time trying to find where the actual check is occurring that is hiding macros, but am at a loss.

Thanks,
Matt

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev