Bug 1277650 - part 2 - more explicit friending between NativeStubImpl and ProxyNativeCall; r=darchons

clang complains about specializations of NativeStubImpl not being able
to see the private constructor of ProxyNativeCall.  While
ProxyNativeCall includes a friend declaration for NativeStubImpl, it's
not obvious *which* NativeStubImpl is being friended, as NativeStubImpl
hasn't been forward declared and exists in a completely separate
namespace.  Forward declaring NativeStubImpl and adjusting the friend
declaration makes everything more correct.
This commit is contained in:
Nathan Froyd 2016-06-06 16:58:55 -04:00
parent 7831fb1c31
commit 9e9c7538de

View File

@ -217,6 +217,13 @@ struct UsesNativeCallProxy
}
};
namespace detail {
template<class Traits, class Impl, class Args, bool IsStatic, bool IsVoid>
class NativeStubImpl;
}
namespace {
// ProxyArg is used to handle JNI ref arguments for proxies. Because a proxied
@ -266,7 +273,7 @@ template<class Impl, class Owner, bool IsStatic,
class ProxyNativeCall
{
template<class T, class I, class A, bool S, bool V>
friend class NativeStubImpl;
friend class detail::NativeStubImpl;
// "this arg" refers to the Class::LocalRef (for static methods) or
// Owner::LocalRef (for instance methods) that we optionally (as indicated
@ -425,9 +432,6 @@ namespace detail {
// We need specialization for return type, because void return type requires
// us to not deal with the return value.
template<class Traits, class Impl, class Args, bool IsStatic, bool IsVoid>
class NativeStubImpl;
// Bug 1207642 - Work around Dalvik bug by realigning stack on JNI entry
#ifdef __i386__
#define MOZ_JNICALL JNICALL __attribute__((force_align_arg_pointer))