As it may be implementation dependent.

This time move the macro inside namespaces; hopefully will work with the
integration script.

Added relative link to cmake guide.

proto2 syntax allows the first enum to have a non zero value. This means any
field using that default has a non zero default without having an explicit
default being set. So when deciding what runtime info is needed, don't rely
on an explicit default, always check that the values aren't zero.

Fixes https://github.com/google/protobuf/issues/1453

A protobuf message will be corrupted in the following scenario:
  1. Use LITE_RUNTIME.
  2. Have an optional enum field following some other field.
  3. Update protocol by adding new values to the enum.
  4. Have an old client parse and serialize a message having enum field
      set to a value the client does not understand.
  5. Field preceeding the enum is now corrupted.

The bug is due to the fact that optimized fallthrough in parser code
does not update variablle 'tag' when jumping to the parser code for the
next field.

Overview of changes:
- A new C#-specific command-line option, legacy_enum_values to revert to the old behavior
- When legacy_enum_values isn't specified, we strip the enum name as a prefix, and PascalCase the value name
- A new attribute within the C# code so that we can always tell the original in-proto name

Regenerating the C# code with legacy_enum_values leads to code which still compiles and works - but
there's more still to do.

proto3.

Added a couple unit test proto3 files, for arena_lite and lite. Cloned
the proto3_arena_unittest to test some of the basics of generated code
(and to ensure that the generated proto3 test files are used by some
test).

It doesn't seem to be necessary here, and it pulls other testing headers
during compilation of release protobuf.

This will make it easier to change the enum value names, as it reduces the number of places they're used.

This also renames generate_directories to base_namespace_specified; generating directories is the
immediate *effect* of specifying a base namespace, but with this change the options reflect what has been
specified rather than the effect. (There may be other effects in the future, of course.)

This should have no behavioral changes at all.

This doesn't strictly enforce an 80-column limit, but removes the most egregious violations.
The indentation in the C# generator code is inconsistent in general, unfortunately - if we have
any good tools that can be trusted to reformat, I'd be happy to apply them.

* `csharp_options`: Added `Options` to encapsulate generator options.
   Supported options for now - file_extension, base_namespace
* `{Blah}Generator`: Now accept `Options*` as parameter to constructor
* `csharp_generator.cc`: Parse and populate options
* `Makefile.am`: Added `csharp_options.h`
* `extract_includes.bat.in`: Added `csharp_options.h`

Refactoring code to two commits. This is the first commit

For fixing MSVC

stubs/common.h undefines the GetMessage macro introduced in windows.h
map_test however include stubs/common.h before windows.h is transitively
included. This hack force map_test.cc to include windows.h first, so we
have a chance to undefine the GetMessage macro.

Referencing data member table_ in static functions break certain
platforms. Change it to refer to the declare type void** instead.

iostream is not actually necessary here, and it introduces unnecessary
static initializers.

The template can be specialized on primitives, e.g. double, where
converting NULL will trigger a warning.

fix warning treated as error prevents building on 64-bit windows.

NOTE: This is a binary breaking change as structure sizes have changed size
and/or order.

- Drop capturing field options, no other options were captured and other mobile
  targeted languages don't try to capture this sort information (saved 8
  bytes for every field defined (in static data and again in field descriptor
  instance size data).
- No longer generate/compile in the messages/enums in descriptor.proto. If
  developers need it, they should generate it and compile it in. Reduced the
  overhead of the core library.
- Compute the number of has_bits actually needs to avoid over reserving.
- Let the boolean single fields store via a has_bit to avoid storage, makes
  the common cases of the instance size smaller.
- Reorder some flags and down size the enums to contain the bits needed.
- Reorder the items in the structures to manually ensure they are are packed
  better (especially when generating 64bit code - 8 bytes for every field,
  16 bytes for every extension, instance sizes 8 bytes also).
- Split off the structure initialization so when the default is zero, the
  generated static storage doesn't need to reserve the space. This is batched
  at the message level, so all the fields for the message have to have zero
  defaults to get the saves. By definition all proto3 syntax  files fall into
  this case but it also saves space for the proto2 that use the standard
  defaults. (saves 8 bytes of static data for every field that had a zero
  default)
- Don't track the enums defined by a message. Nothing in the runtime needs it
  and it was just generation and runtime overhead. (saves 8 bytes per enum)
- Ensure EnumDescriptors are started up threadsafe in all cases.
- Split some of the Descriptor initialization into multiple methods so the
  generated code isn't padded with lots of zero/nil args.
- Change how oneof info is feed to the runtime enabling us to generate less
  static data (8 bytes saved per oneof for 64bit).
- Change how enum value informat is capture to pack the data and only decode
  it if it ends up being needed. Avoids padding issues causing bloat of 64bit,
  and removes the needs for extra pointers in addition to the data (just the
  data and one pointer now).

This change was previously done in //third_party in CL 108656107 but never made it to the open source project and was overwritten in an update.

Add a compile test to confirm things are working as expected.