* Adopt php_metadata_namespace in php code generator
The php_metadata_namespace is corresponded to the relative directory of
the metadata file. e.g., previously, the metadata file of foo.proto was
GPBMetadata/Foo.php. If the php_metadata_namespace is "Metadata\\Bar",
the metadata file will be Metadata/Bar/Foo.php.
* Handle empty php_metadata_namespace
Pointer Arguments to memcpy can not be null in UndefinedBehaviorSanitizer.
In this case, both the memory and the size was zero. This change allows
protoc to run under UndefinedBehaviorSanitizer.
* Fix memory leak of exceptions raised by RaiseException()
Currently exceptions raised by RaiseException() is never deallocated because:
* ARC is disabled for this library: https://github.com/google/protobuf/blob/master/BUILD#L913
* It is constructed with `+alloc` but is never `-release`d.
This change fixes the issue by using `-[NSException exceptionWithName:...]` instead, which returns an autoreleased instance, so it is deallocated properly.
* Fix format.
With this fix, Unity using IL2CPP should work with one of two
approaches:
- Call `FileDescriptor.ForceReflectionInitialization<T>` for every
enum present in generated code (including oneof case enums)
- Ensure that IL2CPP uses the same code for int and any int-based
enums
The former approach is likely to be simpler, unless IL2CPP changes
its default behavior. We *could* potentially generate the code
automatically, but that makes me slightly uncomfortable in terms of
generating code that's only relevant in one specific scenario. It
would be reasonably easy to write a tool (separate from protoc) to
generate the code required for any specific set of assemblies, so
that Unity users can include it in their application. We can always
decide to change to generate it automatically later.
For google/or-tools, on windows, we need to use `import "google/protobuf/wrappers.proto";` since we want "optional" int64 and in version3 POD get default value...
-> so we use "google.protobuf.Int64Value" since 0 is a valid value and different from "not set" for our use case.
The tests can run as what Apple calls a Logic Test (under xctest), which means
it doesn't have to load an full UI App under the simulator, which speeds things
up a fair amount.