<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    <div class="moz-cite-prefix">On 22/10/2013 20:26, Richard Smith
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAOfiQqmtDXAzm_cwRENkcfkCc0C7jNGAYpvRoKcD0bcuaPJx8A@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div>
          <div>+def ext_retained_language_linkage : Extension<</div>
          <div>+  "friend function %0 retaining previous language
            linkage is an extension">,</div>
          <div>+
             InGroup<DiagGroup<"retained-language-linkage">>;</div>
        </div>
        <div><br>
        </div>
        <div>I'd like this diagnostic to be clearer that</div>
        <div><br>
        </div>
        <div>  extern "C" void f();</div>
        <div>  struct S {</div>
        <div>    friend void f();</div>
        <div>  };</div>
        <div><br>
        </div>
        <div>is fine but</div>
        <div><br>
        </div>
        <div>  extern "C" void f();</div>
        <div>  extern "C++" {</div>
        <div>    struct S {</div>
        <div>      friend void f();</div>
        <div>    };</div>
        <div>  }</div>
        <div><br>
        </div>
        <div>is the extension. Maybe add a note pointing at the
          innermost surrounding linkage specification that we're
          ignoring?</div>
      </div>
    </blockquote>
    <br>
    I don't think that's the right way to look at this change.<br>
    <br>
    My interpretation of the spec is very much that friend function
    declarations don't have a linkage spec in the first place because
    they don't introduce a function name:<br>
    <br>
    <pre wrap="">[dcl.link]p4:
  In a linkage-specification,
  the specified language linkage applies to the function  types  of  all
  function declarators, function names, and variable names **introduced** by
  the declaration(s).</pre>
    <br>
    So the fact we're "ignoring" the innermost linkage spec is at best
    an implementation detail that I'd prefer not to leak any further
    into a diagnostic.<br>
    <br>
    I know my view differs from yours in that I don't see this is a
    correctness deviation or relaxation of the standard :-)<br>
    <br>
    On the other hand, highlighting the selected outer linkage spec
    _would_ be nice to do when diagnosing linkage specs in general.<br>
    <br>
    I have some patches back from when the linkage spec work started in
    2010 to improve diags. Thinking to get back to it, but either way,
    digging up and passing around the LinkageSpecDecl belongs in a
    separate patch.<br>
    <br>
    <blockquote
cite="mid:CAOfiQqmtDXAzm_cwRENkcfkCc0C7jNGAYpvRoKcD0bcuaPJx8A@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div><br>
        </div>
        <div>+      // The friend object kind isn't yet complete so
          check IDNS directly.</div>
        <div>+      if (New->getIdentifierNamespace() &
          Decl::IDNS_OrdinaryFriend) {</div>
        <div><br>
        </div>
        <div>We don't care whether it's FOK_Declared or FOK_Undeclared,
          so why not:</div>
        <div><br>
        </div>
        <div>  if (New->getFriendObjectKind() != FOK_None) {</div>
        <div><br>
        </div>
        <div>?</div>
      </div>
    </blockquote>
    <br>
    Sure, let's do that.<br>
    <br>
    So, I'm looking to land this patch with the getFriendObjectKind()
    change and then contining with general improvement of linkage spec
    diagnostics.<br>
    <br>
    Let me know if you feel strongly enough about the diagnostic to
    object to landing this in the next day or so.<br>
    <br>
    Alp.<br>
    <br>
    <br>
    <br>
    <blockquote
cite="mid:CAOfiQqmtDXAzm_cwRENkcfkCc0C7jNGAYpvRoKcD0bcuaPJx8A@mail.gmail.com"
      type="cite">
      <div class="gmail_extra"><br>
        <br>
        <div class="gmail_quote">On Tue, Oct 22, 2013 at 10:46 AM, Alp
          Toker <span dir="ltr"><<a moz-do-not-send="true"
              href="mailto:alp@nuanti.com" target="_blank">alp@nuanti.com</a>></span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello
            Richard,<br>
            <br>
            With this patch, friend function declarations will retain
            the language<br>
            linkage specified for previous declarations instead of
            emitting an error<br>
            diagnostic.<br>
            <br>
            The feature is known to be compatible with GCC and MSVC and
            permits a<br>
            language to be specified indirectly where it cannot
            otherwise be written<br>
            directly in class scope.<br>
            <br>
            Further to the previous patch, this feature is now a clang
            extension so<br>
            warnings can be enabled/disabled with a
            -Wretained-language-linkage flag<br>
            while we seek clarifications to the language standard. Tests
            have been<br>
            moved to SemaCXX/linkage-spec.cpp.<br>
            <span class="HOEnZb"><font color="#888888"><br>
                Alp.<br>
                <br>
                --<br>
                <a moz-do-not-send="true" href="http://www.nuanti.com"
                  target="_blank">http://www.nuanti.com</a><br>
                the browser experts<br>
                <br>
              </font></span></blockquote>
        </div>
        <br>
      </div>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
<a class="moz-txt-link-freetext" href="http://www.nuanti.com">http://www.nuanti.com</a>
the browser experts
</pre>
  </body>
</html>