| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
| |
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.
|
| | |
|
| | |
|
| |\
| |
| | |
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.
|
| | |
| |
| |
| |
| |
| | |
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.
|
| |/ |
|
| | |
|
| | |
|
| | |
|
| |\
| |
| | |
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.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
- Removed a TODO without change in DescriptorPool.LookupSymbol - the TODOs were around performance, and this is only used during descriptor initialization
- Make the CodedInputStream limits read-only, adding a static factory method for the rare cases when this is useful
- Extracted IDeepCloneable into its own file.
|
| |\
| |
| | |
Implement Keys and Values as views in MapField
|
| | | |
|
| | | |
|
| |/
|
|
|
| |
This is a bit of a grotty hack, as we need to sort of fake proto2 field presence, but with only a proto3 version of the descriptor messages (a bit like oneof detection).
Should be okay, but will need to be careful of this if we ever implement proto2.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Now the generated code doesn't need to check for end group tags, as it will skip whole groups at a time.
Currently it will ignore extraneous end group tags, which may or may not be a good thing.
Renamed ConsumeLastField to SkipLastField as it felt more natural.
Removed WireFormat.IsEndGroupTag as it's no longer useful.
This mostly fixes issue 688.
(Generated code changes coming in next commit.)
|
| | |
|
| |
|
|
|
|
|
|
| |
stream", rather than using an awkward out parameter.
This simplifies quite a lot of code.
Generated code in next commit.
|
| |
|
|
|
|
| |
expected to.
We should now have no conformance failures.
|
| | |
|
| |
|
|
|
| |
This is expected to be the cause of the conformance test failures.
Generated code in next commit.
|
| | |
|
| | |
|
| | |
|
| |\
| |
| | |
Add ReleaseSigned configuration for C#
|
| | |
| |
| |
| | |
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.
|
| | |
|
| |
|
|
| |
(Shows the benefit of unit testing even code "too simple to fail"...)
|
| |
|
|
|
| |
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.
|
Jon Skeet
Jan Tattermusch
Jon Skeet
Jan Tattermusch