| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Compiler changes
* Generated code changes
* Library changes
* Compiler style changes
* Generated style changes
* Fix Windows build errors
* Implement changes from review
* Reintroduce proto2 check
* Compiler changes (required handling review)
* Generated code changes (required handling review)
* Library changes (required handling review
* Field presence rewrite (compiler changes)
* Field presence rewrite (generated code changes)
* Compiler comment
* IFieldAccessor.HasValue library implementation
* Remove Clear methods and default values from proto3 code (Compiler)
* Remove Clear methods and default values from proto3 code (Generated)
* Remove Clear methods and default values from proto3 code (Library)
* Fix distcheck error
* Rewrite default string values to use base64 and convert
* Library changes (IMessage2)
* Compiler changes (IMessage2)
* Generated changes (IMessage2)
* Rebased and regenerated
* Compiler changes (initialized extension)
* Generated changes (initialized extension)
* Library changes (initialized extension)
* Refactor MessageExtensions.IsRequired
* Move string default value creator and bytes default value creator back to seperate methods
* Dead code cleanup
* Fixed segmentation fault
Removed unused header method declarations
|
| |
|
|
|
|
|
| |
By default, unknown fields are preserved when parsing. To discard
them, use a parser configured to do so:
var parser = MyMessage.Parser.WithDiscardUnknownFields(true);
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
(Generated code changes in next commit.)
|
| | |
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
| |
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 future.
|
| |
|
|
|
|
|
| |
it from the generated code soon.
Additionally, change it to return the value passed, and make it generic with a class constraint.
A separate method doesn't have the class constraint, for more unusual scenarios.
|
|
|
We'll see what I've missed when CI fails...
|
