[Bug c++/114990] New: Compiler errors in <type_traits> compiling a module-based app

[Bug c++/114990] New: Compiler errors in <type_traits> compiling a module-based app

[admin at hexadigm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114990

            Bug ID: 114990
           Summary: Compiler errors in <type_traits> compiling a
                    module-based app
           Product: gcc
           Version: 14.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: admin at hexadigm dot com
  Target Milestone: ---

Hi there,

This is a bit lengthy (code to reproduce reasonably short though) but intended
to provide sufficient detail. I'm getting numerous errors in the <type_traits>
(standard) header in V14.1 of GCC. It's a module-based app and the code below
is stripped down to the minimum required to demonstrate the issue (stripped
down so does nothing but should at least compile AFAIK - it doesn't). You can
run it in Compiler Explorer at https://godbolt.org/z/sh3c3TK8Y (same code
posted below but link itself relies on CMake - read on). See errors in top
executable window at latter link (targeting GCC 14.1) but compiles fine in
bottom executable window (targeting latest Clang). Also compiles in MSVC (not
shown at above link).

Note that if you simply comment out the #include <type_traits> statement seen
in "TypeTraits.h" OR the #include <iostream> statement seen in
"CompilerVersions.h" the errors disappear.

Unfortunately I have little experience in GCC (I specialize on MSFT platforms)
and don't have my own machine set up to test the situation (in GCC) so I depend
on CMake in the Compiler Explorer environment (not too experienced with CMake
either for that matter but very experienced in C++ - modules still relatively
new to most though).

Note that the "CMakeLists.txt" file at the above link is a bit elaborate
(didn't strip that particular file down) but it handles Clang and MSVC without
issue, and should handle GCC as well (designed to assuming no errors). It does
in fact when I compile a header-based version of the app (not module-based)
which I can control via switches passed to CMake. Presumably (hopefully) it's
not a CMake issue in the module version (or perhaps some issue with Compiler
Explorer) but I don't have access to a pure GCC environment to test things
further. Someone at your end will have to (sorry) but at this point it looks
like a GCC issue.

Here's the code (5 very short files):

###############################################################
$ cat CompilerVersions.h

#ifndef COMPILER_VERSIONS
    #define COMPILER_VERSIONS

    // #defined in "CompilerVersions.cppm" so only when that file is building
(and no other time)
    #if !defined(STDEXT_BUILDING_MODULE_COMPILERVERSIONS)
        import CompilerVersions;
        #define DECLARE_MACROS_ONLY
    #endif

    #if !defined(DECLARE_MACROS_ONLY)
        #include <iostream>
    #endif
#endif

###############################################################
$ cat CompilerVersions.cppm

module;

#define STDEXT_BUILDING_MODULE_COMPILERVERSIONS
#include "CompilerVersions.h"
#undef STDEXT_BUILDING_MODULE_COMPILERVERSIONS

export module CompilerVersions;

###############################################################
$ cat TypeTraits.h

#ifndef TYPETRAITS
    #define TYPETRAITS

    #include "CompilerVersions.h"

    // #defined in "TypeTraits.cppm" so only when that file is building (and no
other time)
    #if !defined(STDEXT_BUILDING_MODULE_TYPETRAITS)
        #include <type_traits>
        import TypeTraits;
    #endif
#endif

###############################################################
$ cat TypeTraits.cppm

module;

#define STDEXT_BUILDING_MODULE_TYPETRAITS
#include "TypeTraits.h"
#undef STDEXT_BUILDING_MODULE_TYPETRAITS

export module TypeTraits;

###############################################################
$ cat Main.cpp

#include "TypeTraits.h"

int main()
{
    return 0;
}

I'm not sure what the command line is to compile the above code directly in GCC
(again, not a GCC developer - some should verify it) but presumably the
following or something similar (or all consolidated into one command if doable,
but would have to research it):

Compile the module interface units:
$ g++ -std=c++20 -fmodules-ts --module-interface -c CompilerVersions.cppm -o
CompilerVersions.o
$ g++ -std=c++20 -fmodules-ts --module-interface -c TypeTraits.cppm -o
TypeTraits.o

Compile the main program:
$ g++ -std=c++20 -fmodules-ts Main.cpp CompilerVersions.o TypeTraits.o -o Main

In Compiler Explorer itself (again, where I'm using CMake instead), many errors
result in <type_traits> but I'd expect the same or similar errors when running
the above GCC commands directly (TBD). Some of them are redefinition errors
which is suspicious given the nature of headers and modules in the same app. To
this end, and I have no idea if it actually has anything to do with the
problem, the "import CompilerVersions;" statement seen in "CompilerVersions.h"
does wind up in the global module fragment section of "TypeTraits.cppm" (where
headers normally go, not import statements), so I'm wondering if that has
something to do with it. If it is the cause, I'm not aware of any illegalities
(or undefined behaviour) in the standard on the use of "import" statements in
the global module fragment section, but it can happen indirectly such as in
cases like this. That is, should someone (as I have) decide to import a
dependency in a header instead of #including it in the traditional way
(especially during the transition from headers to modules), and the header then
winds up in the global module fragment section of a module, the "import"
statement for that dependency (indirectly) winds up there too of course. Could
this somehow be the cause here (just idle speculation only at this point)?

Thanks for your assistance.

[Bug c++/114990] Compiler errors in <type_traits> compiling a module-based app

[ppalka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114990

Patrick Palka <ppalka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ppalka at gcc dot gnu.org
         Depends on|                            |99000

--- Comment #1 from Patrick Palka <ppalka at gcc dot gnu.org> ---
After preprocessing, it seems Main.cpp basically boils down to:

import CompilerVersions; // #1
#include <type_traits>   // #2
import TypeTraits;       // #3

int main()
{
    return 0;
}

The issue here seems to be the #include <type_traits> appearing after the
import of CompilerVersions which (indirectly) also includes <type_traits> (in
its GMF).  GCC currently supports import-after-include GMF merging (so #2
followed by #3 is OK) not but include-after-import.  See also
https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Modules.html

So one workaround would be to arrange that all #includes come before imports
which might include the same thing.  Another workaround would be to compile the
problematic headers (<type_traits> in this case) as a header unit so that
#includes thereof implicitly translated into imports, via e.g.

g++ -fmodules-ts -x c++-system-header type_traits


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99000
[Bug 99000] [modules] merging of textual redefinitions: declaration
std::__copy_move_a2 conflicts with import

[Bug c++/114990] Compiler errors in <type_traits> compiling a module-based app

[admin at hexadigm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114990

--- Comment #2 from Larry Smith <admin at hexadigm dot com> ---
Thanks for the (very) fast turn-around (!). I'll look into the situation over
the coming days and reply further (so if you can keep the issue alive for now,
thanks). Just briefly though, can you (or anyone) confirm that the
"include-after-import" issue you cited as the probable cause will be rectified
eventually or is the situation permanent. Thanks again (appreciated).

[Bug c++/114990] Compiler errors in <type_traits> compiling a module-based app

[ppalka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114990

--- Comment #3 from Patrick Palka <ppalka at gcc dot gnu.org> ---
I reckon it's not something we can fix/implement in a point release of GCC 14,
but hopefully for 15...