This is primarily for access to comments, which would be expected to be available in a protoc plugin.
The implementation has two fiddly aspects:
- We use a Lazy<T> to avoid building the map before cross-linking. An alternative would be to crosslink at the end of the constructor, and remove the calls to CrossLink elsewhere. This would be generally better IMO, but deviate from the Java code.
- The casts to IReadOnlyList<DescriptorBase> are unfortunate. They'll always work, because these lists are always ReadOnlyCollection<T> for a descriptor type... but we can't use IList<DescriptorBase> as that's not covariant, and it's annoyingly fiddly to change the field to be of type ReadOnlyCollection<T>.
This performs more testing for field descriptors built from byte
strings too, but that's mostly incidental. The chief intent is to
check that cross-linking occurs.
* Give a unique category to each test.
This change introduce a TestCategory enum to ConformanceRequest. Existing tests
are divided into three categories: binary format test, json format test and json
format (ignore unknown when parsing) test. For the previous two categories, there
is no change to existing testee programs. For tests with the last category, testee programs
should either enable ignoring unknown field during json parsing or skip the test.
* Fix python test
* Fix java
* Fix csharp
* Update document
* Update csharp generated code
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.
The SampleEnumMethod method was previously only called via
reflection, so the Unity linker thought it could be removed. Ditto
the parameterless constructor in ReflectionHelper.
This PR should avoid that issue, reducing the work needed by
customers to use Google.Protobuf from Unity.
For oneofs, to get the case, we need to call the property that
returns the enum value. We really want it as an int, and modern
runtimes allow us to create a delegate which returns an int from the
method. (I suspect that the MS runtime has always allowed that.)
Old versions of Mono (e.g. used by Unity3d) don't allow that, so we
have to convert the enum value to an int via boxing. It's ugly, but
it should work.
This should work on Unity, Mono and .NET 3.5 as far as I'm aware.
It won't work on platforms where reflection itself is prohibited,
but that's a non-starter basically.
This will allow SourceLink as per #4179, and mean that we can use C#
7.0 language features in the library (but not in generated code).
This does not affect which platforms we're *targeting*, so end users
won't see any difference.
It would be nice to update to 2.1.4, but AppVeyor's "Visual Studio
2017" environment is only 2.0.3.
By default, unknown fields are preserved when parsing. To discard
them, use a parser configured to do so:
var parser = MyMessage.Parser.WithDiscardUnknownFields(true);
