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!** :)

Reply via email to