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.
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.
This seems to be some code evolution side effects. Back when there was a custom
string class, we couldn't really error when we finally saw the string was bad
so we had to return the empty string, but now that full validation is done
up front, it can error out.
* `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
This is required to allow Tensorflow to build on Android without hacks. Currently we create a dummy pthread library just to satisfy this dependency for a library that does not exist on Android. See https://github.com/google/protobuf/issues/1373 for more context.
I've moved both protoc.exe and the proto files out of Google.Protobuf.
The .proto files aren't a slam-dunk, but it feels like they belong with protoc as you'd *use* them with protoc.
It's not clear to me whether we really need both an x86 and x64 version of protoc.exe, as x86 would work on 64-bit Windows anyway. Discuss :)
This makes no externally visible behavioral changes. Internally and non-behaviorally:
- We use a field (compiler-generated) to store the JsonName to avoid recomputing it repeatedly
- The documentation for JsonName is updated to reflect the meaning better
- Readonly autoprops and expression-bodied properties used where possible
