| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
(And likewise ignore the prefix in unpack.)
Fixes issue #1459.
|
|
|
|
| |
JSON tests fail, as we're not using OriginalNameAttribute yet.
|
|
|
|
| |
(NCrunch noticed these.)
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
On deserialization, missing values for message types
are replaced with a "default" message.
|
|
|
|
|
|
|
| |
This involves quoting timestamp/duration/field-mask values, even when they're not in fields.
It's better for consistency.
Fixes issue #1097.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This includes all the well-known types except Any.
Some aspects are likely to require further work when the details of the JSON parsing expectations are hammered out in more detail. Some of these have "ignored" tests already.
Note that the choice *not* to use Json.NET was made for two reasons:
- Going from 0 dependencies to 1 dependency is a big hit, and there's not much benefit here
- Json.NET parses more leniently than we'd want; accommodating that would be nearly as much work as writing the tokenizer
This only really affects the JsonTokenizer, which could be replaced by Json.NET. The JsonParser code would be about the same length with Json.NET... but I wouldn't be as confident in it.
|
| |
|
| |
|
|
|
|
| |
This seems remarkably little code, but it appears to work. I can add tests for invalid structs at some point, once the general approach is approved.
|
|
|
|
| |
This is taking an approach of putting all the logic in JsonFormatter. That's helpful in terms of concealing the details of whether or not to wrap the value in quotes, but it does lack flexibility. I don't *think* we want to allow user-defined formatting of messages, so that much shouldn't be a problem.
|
|
|
|
| |
Use ' instead of " in the expected JSON, then replace it before asserting.
|
| |
|
|
|
|
| |
reflection API rethink before doing the rest.
|
|
We'll see what I've missed when CI fails...
|