[PATCH] D67414: [AST] Treat "inline gnu_inline" the same way as "extern inline gnu_inline" in C++ mode

[Richard Smith - zygoloid via Phabricator via cfe-commits]

rsmith added a comment.

In D67414#1668475 <https://reviews.llvm.org/D67414#1668475>, @mstorsjo wrote:

> In D67414#1668443 <https://reviews.llvm.org/D67414#1668443>, @rsmith wrote:
>
> > Seems very surprising to me that the `gnu_inline` attribute has different behavior in their C and C++ frontends. That said, it looks like it's a behavior that they document; their documentation says "In C++, this attribute does not depend on extern in any way, but it still requires the inline keyword to enable its special behavior." and that matches their observed behavior. And they behave this way even for functions in `extern "C"` blocks. The question for us, then, is do we want to be compatible with C source code built as C++ (that is, the status quo) and C++ source code using this attribute and targeting older versions of Clang, or with g++?
>
>
> I think it's a rather uncommon combination (I think most use of gnu_inline is together with extern), so I wouldn't think that there's a lot of users relying on the current behaviour (in clang-only codebases), but I have no data to back it up with.
>
> > Is Clang's current behavior actually causing problems for some real use case? Changing this behavior is not without risk, and the old behavior is certainly defensible.
>
> It did come up in mingw-w64 recently; new header additions (that were developed with gcc) broke when built with clang (due to multiple definitions of a symbol). It's been rectified for now by avoiding this combination (for compatibility with existing clang versions) though.


OK. If this is causing compatibility pain in practice, following GCC here seems reasonable. We should at least produce a warning on `gnu_inline` without `extern` in C++ mode, though.


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67414/new/

https://reviews.llvm.org/D67414