| Commit message (Collapse) | Author | Age |
|---|
| |\
| |
| | |
Ensure all formatted well-known-type values are valid JSON
|
| |\ \
| | |
| | | |
Remove unused method in FieldCodec.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
This involves quoting timestamp/duration/field-mask values, even when they're not in fields.
It's better for consistency.
Fixes issue #1097.
|
| | |/
|/|
| |
| |
| |
| | |
- 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 method was last used a very long time ago, if ever.)
|
| |
|
|
|
| |
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
|
| |\ \
| | |
| | | |
Make nuget package support coreCLR
|
| | | | |
|
| |/ / |
|
| | | |
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
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.
|
| |\ \
| | |
| | | |
Move the creation of the "fields by JSON name" dictionary to the descriptor
|
| | | |
| | |
| | |
| | |
| | |
| | | |
This is only thrown directly by JsonTokenizer, but surfaces from JsonParser as well. I've added doc comments to hopefully make everything clear.
The exception is actually thrown by the reader within JsonTokenizer, in anticipation of keeping track of the location within the document, but that change is not within this PR.
|
| | |/
|/|
| |
| | |
Fixes issue #932.
|
| |/ |
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
| |
The nullable value type fields already worked, but the use of the CLR property concealed the difference between string and StringWrapper fields.
|
| |
|
|
| |
equality).
|
| |
|
|
| |
The included C# test will fail until the regenerated code is used, which is in the next commit.
|
| |\
| |
| | |
Support ToString in RepeatedField and MapField.
|
| | |
| |
| |
| |
| |
| | |
This changes how we approach JSON formatting in general - instead of looking at the field a value came from, we just look at the type of the value. It's possible this *could* be slightly inefficient, but if we start caring about JSON performance deeply, we'll probably want to rewrite all of this anyway. It's definitely simpler this way.
When we support dynamic messages, we'll need to modify JsonFormatter to handle enum values, as they won't come be "real" .NET enums at that point. It shouldn't be hard to do though.
|
| |/ |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
There are now summaries for:
- The Types nested class (which holds nested types)
- The file descriptor class for each proto
- The enum generated for each oneof
(Also fixed two typos.)
Generated code in next commit.
|
| |\
| |
| | |
Generate C# directory hierarchy with new option
|
| | |
| |
| |
| |
| | |
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.)
|
| |/
|
|
| |
Other changes are due to the well-known types changing without us regenerating.
|
| |\
| |
| | |
Include descriptor.proto in nuget package
|
| | | |
|
| |/
|
|
|
|
|
|
|
|
|
| |
We now do this in protoc instead of the generation simpler.
Benefits:
- Generation script is simpler
- Detection is simpler as we now only need to care about one filename
- The embedded descriptor knows itself as "google/protobuf/descriptor.proto" avoiding dependency issues
This PR also makes the "invalid dependency" exception clearer in terms of expected and actual dependencies.
|
Jan Tattermusch
Jon Skeet
Jan Tattermusch
Jon Skeet
Gabriel Kliot