[PPAPI] Added PP_VARTYPE_RESOURCE as a PP_VarType enum value.

ppapi/proxy/raw_var_data.cc

 // Copyright (c) 2013 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "ppapi/proxy/raw_var_data.h"
 
 #include <stack>
 
 #include "base/containers/hash_tables.h"
 #include "base/stl_util.h"
@@ skipping 222 matching lines @@
     case PP_VARTYPE_OBJECT:
       return new BasicRawVarData();
     case PP_VARTYPE_STRING:
       return new StringRawVarData();
     case PP_VARTYPE_ARRAY_BUFFER:
       return new ArrayBufferRawVarData();
     case PP_VARTYPE_ARRAY:
       return new ArrayRawVarData();
     case PP_VARTYPE_DICTIONARY:
       return new DictionaryRawVarData();
+    case PP_VARTYPE_RESOURCE:
+      // TODO(mgiuca): Add ResourceRawVarData. (http://crbug.com/177017)
+      // This path will be reached if a NaCl module attempts to pass a
+      // PP_VARTYPE_RESOURCE in a message.
+      NOTIMPLEMENTED();
+      CHECK(false) << "Serializing PP_VARTYPE_RESOURCE is not supported.";

[raymes, 2013/09/11 22:52:29]

I realise that you are going to be changing this soon, but I think it might be
better to maintain the existing behavior here and just have a NOTREACHED() here.

[Matt Giuca, 2013/09/12 07:08:24]

OK, fair enough.

That will result in a NULL pointer dereference in the plugin module on the
release build. But I suppose that a) that is equivalent to the current behaviour
anyway, if the user decides to set a var's type to 100, and b) that is no worse
than a checkfail (just harder to diagnose).

+      return NULL;
   }
   NOTREACHED();
   return NULL;
 }
 
 RawVarData::RawVarData() : initialized_(false) {
 }
 
 RawVarData::~RawVarData() {
 }
@@ skipping 403 matching lines @@
       return false;
     if (!m->ReadUInt32(iter, &value))
       return false;
     children_.push_back(make_pair(key, value));
   }
   return true;
 }
 
 }  // namespace proxy
 }  // namespace ppapi