+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 <[email protected]> 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
>
>
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
