On Mon, Jun 22, 2026 at 9:22 AM Yexuan Xiao <bizwen_at_[hidden]> wrote:

> Of course I know that both anonymous namespaces and static are used for
> internal linkage, and that modules haven't changed anything about that. I
> don't know why you brought up anonymous namespace. I never mentioned it,
> because all the problematic code I encountered uses the static keyword. I
> forgot to include the issue URL when writing the email, you can take a look
> at https://github.com/llvm/llvm-project/issues/195661 and
> https://github.com/microsoft/STL/pull/5805.
>

Ah, I'd call that mainly a vendor issue with Modules, then: people are
reporting to the compiler vendor that their Modules mode cannot actually
compile (1) Boost or (2) their own STL.
https://github.com/llvm/llvm-project/issues/195661#issuecomment-4639344010
in particular sketches a potential (solution/hack) being considered by the
Clang folks, to enable Modules to work with these existing codebases. I
think that's a reasonable direction. What is certainly *un-*reasonable is
to imagine that every existing codebase in the world will start avoiding
`static inline` merely in order to work around open compiler issues related
to Modules mode (which these existing codebases generally don't care about).

Jan Kokemüller wrote
<https://github.com/llvm/llvm-project/issues/195661#issuecomment-4639344010>
:

> While removing static for those inline functions would be the "proper"
> fix (at least when compiling for C++), I think the compiler should handle
> this somehow, since using static inline for inline helper functions is
> such a common idiom in C. Exposing <https://eel.is/c++draft/basic.link#14> those
> functions is not really avoidable. For example, Boost::unordered uses the
> SSE intrinsics internally, but technically exposes them since it's all
> templates. For a C++ library to handle this correctly according to the
> standard, it must wrap all static inline functions in some kind of
> "wrapping layer", and then use *that*. But nobody does this, and it's
> likely that most C++ library authors are not even aware of this problem
> since it all "just works" when using headers.
> Maybe something like this could work:
>
> - special case static inline functions that live in the global
> namespace *and* in the global module fragment
>
>
> - when compiling a module unit, give these functions module linkage
> (similar to the initializer symbol)
>
> Other compiler vendors might try to solve the problem in other ways. But
eventually one-or-more of them will solve it and then we can talk about
standardizing existing practice. Or, technically, if they all give up on
solving it, I guess we might finally agree that "Modules has failed" — but
that seems highly unlikely to me, politically speaking.

Is there a corresponding GCC bug report, too?
Have you talked to Chuanqi Xu and/or Jan Kokemüller about the issue?

–Arthur

>