| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| |
|
|
|
| |
This is the manual code part of the Google.Protobuf library, and tests.
Some tests will fail until codegen is changed and rerun.
|
| | |
|
| |
|
|
|
|
|
| |
- Add a TryUnpack method which doesn't throw if the type is wrong
- Make GetTypeName public for easier determination of the message type
Fixes #3294.
|
| |
|
|
|
|
|
| |
platform (#1727)
Move to dotnet cli for building, and .NET Core (netstandard1.0) as target platform
This also updates the version number to 3.0.0-beta4
|
| |
|
|
|
|
| |
Also added a standalone formatter test, for confidence.
Have validated that undoing the change in 835fb947 breaks the tests
(i.e. we are still testing that the change is required).
|
| | |
|
| |
|
|
|
|
| |
(And likewise ignore the prefix in unpack.)
Fixes issue #1459.
|
| |
|
|
| |
This was in an attempt to fix the wrapper handling corner case, but it's really fiddly.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The usage of ICustomDiagnosticMessage here is non-essential - ToDiagnosticString
doesn't actually get called by ToString() in this case, due to JsonFormatter code. It was
intended to make it clearer that it *did* have a custom format... but then arguably I should
do the same for Value, Struct, Any etc.
Moving some of the code out of JsonFormatter and into Duration/Timestamp/FieldMask likewise
feels somewhat nice, somewhat nasty... basically there are JSON-specific bits of formatting, but
also domain-specific bits of computation. <sigh>
Thoughts welcome.
|
| | |
|
| |
|
|
|
| |
Previously we were incorrectly packing wrapper types.
This also refactors FieldCodec a bit as well, using more C# 6-ness.
|
| |
|
|
|
| |
On deserialization, missing values for message types
are replaced with a "default" message.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This addresses issue #1008, by creating a JsonFormatter which is private and only different
to JsonFormatter.Default in terms of reference equality.
Other plausible designs:
- The same, but expose the diagnostic-only formatter
- Add something to settings to say "I don't have a type registry at all"
- Change the behaviour of JsonFormatter.Default (bad idea IMO, as we really *don't* want the result of this used as regular JSON to be parsed)
Note that just trying to find a separate fix to issue #933 and using that to override Any.ToString() differently wouldn't work for messages that *contain* an Any.
Generated code changes follow in the next commit.
|
| |
|
|
| |
The nullable value type fields already worked, but the use of the CLR property concealed the difference between string and StringWrapper fields.
|
| |
|
|
|
| |
We still need the JSON representation, which relies on something like a DescriptorPool to fetch message types from based on the type URL. That will come a bit later.
(The DescriptorPool comment in this commit is just a note which will prove useful if we use DescriptorPool itself.)
|
| | |
|
| | |
|
| |
|
|
|
| |
While I've provided operators, I haven't yet provided the method equivalents. It's not clear to me that
they're actually a good idea, while we're really targeting C# developers who definitely *can* use the user-defined operators.
|
| |
|
|
|
|
|
|
|
|
| |
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?)
|
| |
|
|
| |
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 :)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
We'll see what I've missed when CI fails...
|
Warren Falk
Jon Skeet
Jon Skeet
Jos Hickson