aboutsummaryrefslogtreecommitdiff
path: root/csharp/src/Google.Protobuf.Test/Reflection/DescriptorsTest.cs
Commit message (Collapse)AuthorAgeFilesLines
* Simplify descriptor testsJon Skeet2018-09-221-13/+13
| | | | | Rather than converting the proto to a ByteString again, use the existing SerializedData property.
* Cross-link descriptor when building from byte stringsJon Skeet2018-09-101-12/+43
| | | | | | 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.
* Support creating FileDescriptors dynamically from binary data.Jon Skeet2018-08-201-15/+84
| | | | Related to #658 and #5007.
* MMinor fix-ups to C# tests from changes in earlier commitsJon Skeet2017-11-121-12/+22
|
* Regenerate all C# code and make it compileJon Skeet2016-04-201-1/+1
| | | | JSON tests fail, as we're not using OriginalNameAttribute yet.
* Tidy up reflection in advance of attempting to implement DynamicMessage.Jon Skeet2015-11-221-12/+6
| | | | | | | | | There are corner cases where MessageDescriptor.{ClrType,Parser} will return null, and these are now documented. However, normally they *should* be implemented, even for descriptors of for dynamic messages. Ditto FieldDescriptor.Accessor. We'll still need a fair amount of work to implement dynamic messages, but this change means that the public API will be remain intact. Additionally, this change starts making use of C# 6 features in the files that it touches. This is far from exhaustive, and later PRs will have more. Generated code changes coming in the next commit.
* Generated code from previous commit.Jon Skeet2015-11-191-1/+3
|
* Generated code changes and manual changes for previous commit.Jon Skeet2015-11-091-13/+14
|
* add a failing descriptor testJan Tattermusch2015-08-141-0/+7
|
* Fix trivial bug in field orderings.Jon Skeet2015-07-311-0/+13
| | | | (Shows the benefit of unit testing even code "too simple to fail"...)
* expose original binary data for filedescriptorJan Tattermusch2015-07-241-0/+2
|
* Implemented Jan's suggestion of FieldCollection, replacing ↵Jon Skeet2015-07-221-3/+4
| | | | | | | | | | FieldAccessorCollection. I think Jan was actually suggesting keeping both, but that feels redundant to me. The test diff is misleading here IMO, because I wouldn't expect real code using reflection to use several accessors one after another like this, unless it was within a loop. Evidence to the contrary would be welcome :) This change also incidentally goes part way to fixing the issue of the JSON formatter not writing out the fields in field number order - with this change, it does except for oneofs, which we can fix in a follow-up change. I haven't actually added a test with a message with fields deliberately out of order - I'm happy to do so though. It feels like it would make sense to be in google/src/protobuf, but it's not entirely clear what the rules of engagement are for adding new messages there. (unittest_proto3.proto?)
* Added newlinesJon Skeet2015-07-221-1/+1
|
* First pass at making field access simpler.Jon Skeet2015-07-221-0/+15
| | | | This is definitely not ready to ship - I'm "troubled" by the disconnect between a list of fields in declaration order, and a mapping of field accessors by field number/name. Discussion required, but I find that easier when we've got code to look at :)
* Revamp to reflection.Jon Skeet2015-07-211-0/+1
| | | | | | | | | | | | | | | | | Changes in brief: 1. Descriptor is now the entry point for all reflection. 2. IReflectedMessage has gone; there's now a Descriptor property in IMessage, which is explicitly implemented (due to the static property). 3. FieldAccessorTable has gone away 4. IFieldAccessor and OneofFieldAccessor still exist; we *could* put the functionality straight into FieldDescriptor and OneofDescriptor... I'm unsure about that. 5. There's a temporary property MessageDescriptor.FieldAccessorsByFieldNumber to make the test changes small - we probably want this to go away 6. Discovery for delegates is now via attributes applied to properties and the Clear method of a oneof I'm happy with 1-3. 4 I'm unsure about - feedback welcome. 5 will go away 6 I'm unsure about, both in design and implementation. Should we have a ProtobufMessageAttribute too? Should we find all the relevant attributes in MessageDescriptor and pass them down, to avoid an O(N^2) scenario? Generated code changes coming in the next commit.
* First pass at the big rename from ProtocolBuffers to Google.Protobuf.Jon Skeet2015-07-171-0/+223
We'll see what I've missed when CI fails...