Question
CLion 2023.2 C++20 Modules Support on GCC: Incomplete IDE Error Highlighting
Kavi Moss
0 reputation · 18 Jan 2020, 01:06 UTC
68.1K views1
Loading…
0 reputation · 18 Jan 2020, 01:06 UTC
CLion 2023.2 introduced preliminary C++20 module support, but the feature is limited to the Clang compiler. When a CMake project targets GCC 11 or newer and includes a module interface unit, the IDE marks the file as an error, even though GCC compiles the module without issue.
Additionally, the IDE’s module import completion is incomplete and it fails to propagate GCC‑specific module flags (e.g., -fmodules-ts) from CMake to the compiler during module build steps. The “Add CMake option” dialog accepts arbitrary options, yet the module build silently ignores them, causing build failures.
Given these constraints, the goal is to understand the root cause of the IDE error highlighting and the missing flag propagation, and to determine whether this represents a known limitation that will be addressed in future releases or if a workaround is required for cross‑platform builds.
Why does CLion 2023.2 flag GCC module interface units as errors while GCC compiles them successfully?
What steps can be taken to ensure the IDE correctly recognizes and propagates module flags during module build steps?
Will upcoming CLion releases provide full GCC module support?
CLion 2023.2 flags GCC module interface units as errors while GCC builds succeed because the IDE’s static analysis is Clang-centric and the background indexer cannot reliably consume GCC-generated module interfaces. Flag propagation for GCC-specific module options is incomplete in this release, so the IDE may not see the same compiler flags used by the build.
The mismatch is typically between CLion’s internal static analysis engine, clangd, and GCC’s implementation of C++20 module interfaces. clangd attempts to parse the generated module files to provide completion and diagnostics. When the project builds with GCC, the module interface format produced by GCC is not the same as Clang’s, so clangd can misinterpret or fail to load the interface and report false errors. Missing propagation of GCC-specific flags such as -fmodules-ts from CMake to the IDE’s analysis further desynchronizes the indexer from the build.
One diagnostic detail that changes the recommendation is the exact GCC version and the clangd log message for the specific module file. Knowing whether clangd reports an inability to load the module file versus a dependency graph issue determines whether the workaround is flag alignment or using a Clang toolchain for IDE indexing while keeping GCC for builds.
Full GCC module support is not present in CLion 2023.2. JetBrains has indicated GCC module support is planned for later releases contingent on stabilization of GCC’s module format and improved clangd integration. Until then, cross-platform builds with GCC require the synchronization steps above.
Use comments to ask for clarification. Post a solution as an answer.
33,775 reputation · 18 Jan 2020, 02:57 UTC
When CLion generates compile_commands.json from CMake, flags that are added via target_compile_options with generator expressions (e.g., $) may be omitted from the JSON for certain configurations, causing the IDE’s indexer to miss -fmodules-ts for GCC builds. To guarantee the flag is present, add it unconditionally—either with add_compile_options(-fmodules-ts) before the first add_executable or by setting set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fmodules-ts"). After updating CMakeLists.txt, run Tools → CMake → Reload Project and then File → Invalidate Caches / Restart so the indexer re‑reads the updated compile commands and can correctly load GCC‑generated BMI files.
clion
cmake
gcc