Bug 1277650 - part 2 - more explicit friending between NativeStubImpl and ProxyNativeCall; r=darchons
authorNathan Froyd <froydnj@gmail.com>
Mon, 06 Jun 2016 16:58:55 -0400
changeset 300690 9c355864809bd697e7a1b3d6290000852c76d1cd
parent 300689 6a215312a1115143e9408ba1dee85abbb82c5873
child 300691 4cd9cb917c456c8d21da9c58b953480c4df25c25
push id30321
push usercbook@mozilla.com
push dateTue, 07 Jun 2016 13:29:08 +0000
treeherdermozilla-central@7f7c7d24700e [default view] [failures only]
perfherder[talos] [build metrics] [platform microbench] (compared to previous push)
reviewersdarchons
bugs1277650
milestone49.0a1
first release with
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
last release without
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
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.
widget/android/jni/Natives.h
--- a/widget/android/jni/Natives.h
+++ b/widget/android/jni/Natives.h
@@ -212,16 +212,23 @@ struct UsesNativeCallProxy
     template<class Functor>
     static void OnNativeCall(Functor&& call)
     {
         // The default behavior is to invoke the call right away.
         call();
     }
 };
 
+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
 // call may happen outside of the original JNI native call, we must save all
 // JNI ref arguments as global refs to avoid the arguments going out of scope.
 template<typename T>
 struct ProxyArg
 {
@@ -261,17 +268,17 @@ template<class C> struct ProxyArg<LocalR
 // ProxyNativeCall implements the functor object that is passed to
 // UsesNativeCallProxy::OnNativeCall
 template<class Impl, class Owner, bool IsStatic,
          bool HasThisArg /* has instance/class local ref in the call */,
          typename... Args>
 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
     // by HasThisArg) pass into the destination C++ function.
     typedef typename mozilla::Conditional<IsStatic,
             Class, Owner>::Type ThisArgClass;
     typedef typename mozilla::Conditional<IsStatic,
             jclass, jobject>::Type ThisArgJNIType;
@@ -420,19 +427,16 @@ namespace detail {
 // types, e.g. from jobject to jni::Object::Ref. For instance methods, the
 // wrapper methods also convert calls to calls on objects.
 //
 // We need specialization for static/non-static because the two have different
 // signatures (jobject vs jclass and Impl::*Method vs *Method).
 // 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))
 #else
 #define MOZ_JNICALL JNICALL
 #endif
 
 // Specialization for instance methods with non-void return type