[PATCH] PR17337: Retained language linkage

Richard Smith richard at metafoo.co.uk
Tue Oct 22 12:26:53 PDT 2013


+def ext_retained_language_linkage : Extension<
+  "friend function %0 retaining previous language linkage is an
extension">,
+  InGroup<DiagGroup<"retained-language-linkage">>;

I'd like this diagnostic to be clearer that

  extern "C" void f();
  struct S {
    friend void f();
  };

is fine but

  extern "C" void f();
  extern "C++" {
    struct S {
      friend void f();
    };
  }

is the extension. Maybe add a note pointing at the innermost surrounding
linkage specification that we're ignoring?


+      // The friend object kind isn't yet complete so check IDNS directly.
+      if (New->getIdentifierNamespace() & Decl::IDNS_OrdinaryFriend) {

We don't care whether it's FOK_Declared or FOK_Undeclared, so why not:

  if (New->getFriendObjectKind() != FOK_None) {

?


On Tue, Oct 22, 2013 at 10:46 AM, Alp Toker <alp at nuanti.com> wrote:

> Hello Richard,
>
> With this patch, friend function declarations will retain the language
> linkage specified for previous declarations instead of emitting an error
> diagnostic.
>
> The feature is known to be compatible with GCC and MSVC and permits a
> language to be specified indirectly where it cannot otherwise be written
> directly in class scope.
>
> Further to the previous patch, this feature is now a clang extension so
> warnings can be enabled/disabled with a -Wretained-language-linkage flag
> while we seek clarifications to the language standard. Tests have been
> moved to SemaCXX/linkage-spec.cpp.
>
> Alp.
>
> --
> http://www.nuanti.com
> the browser experts
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131022/508d6303/attachment.html>


More information about the cfe-commits mailing list