[BUG] cpp1 module declaration must be at beginning of generated .cpp file

[abuehl]

If the (mixed) .cpp2 input-file begins with a C++20 module declaration, e.g.

module foo;

the generated .cpp file is not valid C++20.

The file begins with various #includes and declarations, followed by the invalidly placed module declaration.

Also, #include's should be placed in the global module fragment.

[threeifbyair]

IMHO, I don't recommend using mainline cppfront if you're going to make significant use of modules. You're much better off using Johel's branch that has decent module support (https://github.com/JohelEGP/cppfront, branch cpp_modules). I did most of Advent of Code 2024 with that (https://github.com/threeifbyair/advent2024) and although it wasn't perfect, it did work.

[abuehl]

Thanks for the pointer, I will try that. We have switched to C++ modules in a ~100 KLOC project using C++20 (MSVC on Windows).

[abuehl]

I have read the rationale of Herb for closing #569 in 2023, but cppfront is currently producing wrong cpp1 code when a mixed syntax input .cpp2 file contains the module keyword. This is a showstopper for us.

As long as cppfront accepts mixed input I think it should at least correctly treat valid cpp1 code that is mixed with cpp2 code.

If/when cppfront should accept the module keyword in cpp2 syntax is a different thing.

[abuehl]

IMHO, I don't recommend using mainline cppfront if you're going to make significant use of modules. You're much better off using Johel's branch that has decent module support (https://github.com/JohelEGP/cppfront, branch cpp_modules). (..)

I can confirm that with commit dacf98c of https://github.com/JohelEGP/cppfront (branch cpp_modules) this bug here doesn't exist.

The cpp1 output file has a correct global module fragment. Declarations and includes are at the right places for example with this .cpp2 input file:

module foo;

import bar;

bla: namespace = {

}

the output file is (correct):

module;

#include "cpp2util.h"

module foo;

import bar;

//=== Cpp2 type declarations ====================================================

#line 1 "x.cpp2"

#line 5 "x.cpp2"
namespace bla {

}


//=== Cpp2 type definitions and function declarations ===========================

#line 1 "x.cpp2"

#line 5 "x.cpp2"
namespace bla {

}


//=== Cpp2 function definitions =================================================

#line 1 "x.cpp2"

#line 5 "x.cpp2"
namespace bla {

}

[abuehl]

We are currently removing usage of C++20 modules from our code base, switching back to header files. I wouldn't be surprised, if C++ modules will be removed from the language in the future. There are just too many issues both with the concept and the implementations. It's probably a wise decision to ignore C++ modules for cppfront, at least for the next few years.

[tattwamasi]

That may be wise, though toolchain module support feels maybe ok iff you can use the newest versions, but I am still of hope that PR #569 can be updated and merged. I think we are at the point where the header file situation vs. module support hits you (the user and maintainer) either way.

[abuehl]

In the mean time we have found a way forward with using modules for our product. We are now using C++ modules and will be keeping them. Back in March, I was quite a bit frustrated with modules. I think cppfront is a very interesting project, but I don't think it will be possible to bring it to a point where it will be mature enough to be useful in production. I've thus stopped looking at cppfront.