* Modify how end tags are encounted in merge code (compiler)
* Modify how end tags are encounted in merge code (generated)
* Modify how end tags are encounted in merge code (library)
* Regenerate generated code through generate_descriptor_proto.sh
Even though the comments were indented to appear to go with the jspb
case/field, protoc doesn't collect comments like that, so these "hanging"
comments actually "attach" to the next thing added to each. Looking at
https://github.com/protocolbuffers/protobuf/pull/5566 you see where
the generated code picked up the comment on the wrong field.
* Down-integrate internal changes to github.
* fix python conformance test
* fix csharp conformance test
* add back java map_lite_test.proto's optimize for option
* fix php conformance test
* Increase C# default recursion limit to 100
This matches the Java and C++ defaults.
* Change compatibility tests to use execution-time default recursion limit
This way the same tests should pass against all versions, even
if the recursion limit changes. (The tests will be testing whether
different messages work, admittedly - but that's probably fine.)
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.
Sydney Acksman
Adam Cozzette
Hao Nguyen
Yilun Chong
Thomas Van Lenten
Bo Yang
Paul Yang
Jon Skeet
Benjamin Krämer
Jon Skeet
Michael Shields
Josh Haberman
Feng Xiao
Jan Tattermusch
Jan Tattermusch
Warren Falk
Sebastian Schuberth
Jisi Liu
Cameron Taggart
David Chennells
ObsidianMinor