[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