| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
Recently, descriptor.proto gained a GeneratedCodeInfo message, which means the generated code conflicts with our type.
Unfortunately this affects codegen as well, although this is a part of the public API which is very unlikely to affect hand-written code.
Generated code changes in next commit.
|
|\
| |
| | |
Ensure that FieldMask, Timestamp and Duration ToString() calls don't throw
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
|/ |
|
|\
| |
| | |
Introduce ICustomDiagnosticMessage to allow for custom string formatting
|
| |
| |
| |
| | |
This fixes issue #933, effectively.
|
| | |
|
| |
| |
| |
| |
| |
| | |
"valueField": null
is parsed appropriately, i.e. that it remembers that the field is set.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
Previously we were incorrectly packing wrapper types.
This also refactors FieldCodec a bit as well, using more C# 6-ness.
|
|/
|
|
|
| |
- Spot an Any without a type URL
- In the conformance test runner, catch exceptions due to generally-invalid JSON
|
|
|
|
|
| |
On deserialization, missing values for message types
are replaced with a "default" message.
|
|\
| |
| | |
Ensure all formatted well-known-type values are valid JSON
|
| |
| |
| |
| |
| |
| |
| | |
This involves quoting timestamp/duration/field-mask values, even when they're not in fields.
It's better for consistency.
Fixes issue #1097.
|
|\ \
| | |
| | | |
Remove unused method in FieldCodec.
|
| |/
| |
| |
| | |
(The method was last used a very long time ago, if ever.)
|
|/
|
|
|
|
| |
- Tighten up on Infinity/NaN handling in terms of whitespace handling (and test casing)
- Validate that values are genuinely integers when they've been parsed from a JSON number (ignoring the fact that 1.0000000000000000001 == 1 as a double...)
- Allow exponents and decimal points in string representations
|
|
|
|
|
| |
The conformance tests now use types which are part of src/google/protobuf, so we need to include src in the proto path.
The notes around "fix-ups" have been out of date for some time now.
|
| |
|
|\
| |
| | |
Handle Any formatting for diagnostic purposes
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
|\ \
| | |
| | | |
Make nuget package support coreCLR
|
| |/ |
|
|/ |
|
|
|
|
| |
This required a rework of the tokenizer to allow for a "replaying" tokenizer, basically in case the @type value comes after the data itself. This rework is nice in some ways (all the pushback and object depth logic in one place) but is a little fragile in terms of token push-back when using the replay tokenizer. It'll be fine for the scenario we need it for, but we should be careful...
|
| |
|
|
|
|
| |
InternalBuildGeneratedFileFrom => FromGeneratedCode)
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Biting off just this bit first as I don't need the changes from a previous PR for this part.
|
|\
| |
| | |
Fixed a bug in CSharp SampleUsage.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| | |
generated types.
Generated code coming in next commit - in a subsequent PR I want to do a bit of renaming and redocumenting around this, in anticipation of DynamicMessage.
|
|/ |
|
| |
|
|\
| |
| | |
Add recursion limit handling to JSON parsing.
|
| |
| |
| |
| | |
Added a TODO around a possible change to the tokenizer API, changing PushBack(token) into just Rewind() or something similar.
|
| |
| |
| |
| | |
Fixes issue #932.
|
|\ \
| | |
| | | |
Move the creation of the "fields by JSON name" dictionary to the descriptor
|