[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.

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++?

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.

If we want to match GCC's behavior for `gnu_inline` in C++ mode, we should think about whether we also want to permit things like:

  __attribute__((__gnu_inline__)) extern inline int externinlinefunc() { return 0; }
  int externinlinefunc() { return 1; }

(with or without the `extern`), which g++ allows and clang rejects.


Repository:
  rC Clang

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

https://reviews.llvm.org/D67414