https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121574
Bug ID: 121574 Summary: [modules] gcc rejects functions who inline-carries TU-local entities in function-body Product: gcc Version: 15.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: shyeyian at petalmail dot com Target Milestone: --- ```cpp module; static void f1() { }; void f2() { f1(); } // ok inline void f3() { f1(); } // rejected struct s { void f3 ( ) { f1(); } }; // implicit inline, rejected export module M; export { using ::f3; using ::s; } ``` is accepted by clang++ and msvc, but rejected by gcc. gcc complains about : error: ‘void f3()’ exposes TU-local entity ‘void f1()’, as inline functions should not carry TU-local entities in implemention. ====== I sincerely **hope** (instead of point out according to the standard, because I'm not clear about the standard here) hope gcc to accept the code above. The latter will bring huge convenience when modulizing many many C++ third-party libraries. One of the common way to compile a library into module is `#include and using`. For example we compile `boost::asio` through: ```cpp module; #include <boost/asio.hpp> export module boost.asio; export namespace boost::asio { using boost::asio::io_context; namespace ip { using boost::asio::ip::tcp; }; // ... } ``` You can see, almost all libraries can be modulized without any change on source code. It is convenient. While clang++ and msvc allows this, gcc throws many errors on `exposes TU-local entity`, like: ``` error: ‘template<class Executor, class CandidateExecutor, class IoContext, class PolymorphicExecutor, class> template<class Function, class Handler> void boost::asio::detail::handler_work_base<Executor, CandidateExecutor, IoContext, PolymorphicExecutor, <template-parameter-1-5> >::dispatch(Function&, Handler&)’ exposes TU-local entity ‘boost::asio::{anonymous}::prefer’ ``` And it is impossible for us to overwrite every `static function` tag inside source code of asio. Same does many other libraries (stdexec, Eigen, etc..., e.g.: Eigen::Dynamic is an `const int` and has internal linkage...) I sincerely hope gcc to accept module exported inline-functions to carry TU-local dependencies in function body. If contribution is welcomed, I will be happy to try contribute on it (at gcc/cp/module.cc -> depset). **Thank you!** :)