Move StringSpaceUsedIncludingSelf to lite library.

Remove a static initializer by removing a global of non-POD type.

Fix GOOGLE_PROTOBUF_ATOMICOPS_ERROR syntax error

Delete kNanosPerSecond from time.cc.

These are banned by the Google style guide, and Chromium has a hard
no-new-static-initializers policy preventing updating to a new version of
libprotobuf unless this is resolved.  This is the first such change, I'll need
to make at least one more in the future.

Luckily, the protobuf source tree already has an alternative to static
initializers in once.h; use that machinery instead.

I defined everything in the .cc file in a blob to replace the old implementation
rather than matching the .h layout precisely; let me know if a different
ordering is preferred.  I also eliminated the macro that used to be used here as
spelling everything out only takes one additional line, and the macro didn't
actually handle all details of using a particular member variable, just the
declaration, so it felt a bit error-prone.

Fix the no-op definitions of GOOGLE_PREDICT_{TRUE,FALSE}

Avoid #including system headers from inside a namespace.

This came up because Chromium downstream modifies the lite library in a way that
requires this function, but I'm upstreaming it because based on the comments in
repeated_field.h, this ought to allow resolution of an existing hack.

I don't know enough about the protobuf code to feel confident trying to resolve
this hack myself, so I've merely updated the TODO comments.

This variable is unused, and thus triggers a build warning on MSVC.

port.h #includes various headers in order to define byteswap functions, but it
currently does so from inside the google::protobuf namespace.  This can cause
bizarre symbol conflicts and other build errors as these headers' contents are
then included inside this namespace.

Instead, #include the relevant headers above the namespace declarations.

Get all tests passing on Python3 (except Python3.4 cpp implementation)

Fix JSON map fields parsing.

Updating to the current protobuf version caused the following build errors in
Chromium when using Clang on Windows:

..\..\third_party\protobuf\src\google/protobuf/stubs/fastmem.h(67,43) :  error: equality comparison with extraneous parentheses [-Werror,-Wparentheses-equality]
  if (GOOGLE_PREDICT_FALSE(n_rounded_down == 0)) {  // n <= 7
                           ~~~~~~~~~~~~~~~^~~~

The problem is that on Windows, GOOGLE_PREDICT_FALSE is #defined to nothing, so
the code expands to 'if ((n_rounded_down == 0))', which Clang warns about.

Clang would not have warned if the extra parentheses came from the macro,
but in this case they don't because the macro is just dropped.

Fix this by making the macros behave as an identity function instead of just
getting dropped.

This is closer to what these macros look like in stubs/port.h internally.

include descriptor.proto in nuget package 

Define GOOGLE_ATTRIBUTE_NOINLINE for MSVC. Workaround for VS2015 Release build compiler bug

Change where we rename Descriptor.cs to DescriptorProtoFile.cs.

We now do this in protoc instead of the generation simpler.

Benefits:
- Generation script is simpler
- Detection is simpler as we now only need to care about one filename
- The embedded descriptor knows itself as "google/protobuf/descriptor.proto" avoiding dependency issues

This PR also makes the "invalid dependency" exception clearer in terms of expected and actual dependencies.

Remove Python 2.5 cruft

Signed-off-by: Dan O'Reilly <oreilldf@gmail.com>

Add tox, Python 2.6 compatibility, and many Python 3 compatibility fixes

Signed-off-by: Dan O'Reilly <oreilldf@gmail.com>

Signed-off-by: Dan O'Reilly <oreilldf@gmail.com>

See issue #240 - MSVC in VS2015 seems to inline a function it shouldn't. My original workaround was to disable inlining for the whole file, but I found a way to do it on just this specific function using __declspec(noinline).
Unfortunately __declspec has to go at the start of the function declaration, while __attribute in GCC can go either before or after. I had to move lots of GOOGLE_ATTRIBUTE_NOLINE to make it compile. I have not yet tested this change with GCC.

Will there be other side effects of defining this, given it wasn't previously?

I also noticed a few functions marked with both the 'inline' keyword, and GOOGLE_ATTRIBUTE_NOINLINE - huh? Is there an explanation for this, or is it an oversight?

Ruby: Conform to C89/C90 variable declaration rules.

Signed-off-by: Dan O'Reilly <oreilldf@gmail.com>

Change-Id: I6cf77f01370204ad4bc7b345a040a9a3de1706a0

Signed-off-by: Dan O'Reilly <oreilldf@gmail.com>

Signed-off-by: Dan O'Reilly <oreilldf@gmail.com>

Signed-off-by: Dan O'Reilly <oreilldf@gmail.com>

Signed-off-by: Dan O'Reilly <oreilldf@gmail.com>

Signed-off-by: Dan O'Reilly <oreilldf@gmail.com>

Signed-off-by: Dan O'Reilly <oreilldf@gmail.com>