- 21 Feb, 2019 1 commit
-
-
Xiang Dai authored
Signed-off-by: Xiang Dai <764524258@qq.com>
-
- 08 Oct, 2018 1 commit
-
-
Benjamin Krämer authored
* Ported FieldMaskUtil from Java to C# * Merged FieldMaskUtil into FieldMaskPartial - Removed FieldMaskUtil - Moved FieldMaskTree to root - Updated tests * Improved tests - Removed internal method FieldMaskTree.GetFieldPaths - Proof FieldMask.Paths only contains expected values * Added FieldMaskTreeTest to Makefile * Added FieldMaskTree to Makefile
-
- 25 Jun, 2018 1 commit
-
-
Sebastian Schuberth authored
This potentially avoids compiler warnings.
-
- 24 Mar, 2017 1 commit
-
-
Jie Luo authored
-
- 28 Feb, 2017 1 commit
-
-
Jie Luo authored
There might be duplicated enum values when allow_alias is true. Add PreferredAlias into OriginalNameAttribute to remove the duplication (#2727)
-
- 23 Feb, 2017 1 commit
-
-
John Brock authored
* Changing DOTNET35 framework symbols in preprocessor directives to the default built-in value of NET35. * Adding extension method StreamExtension.CopyTo for .NET 3.5 because it didn’t exist until .NET 4, and adding associated unit tests.
-
- 03 Nov, 2016 1 commit
-
-
Jon Skeet authored
This affects cases with leading capital letters. This breaks compatibility with previous C# releases, but fixes compatibility with other implementations. See #2278 for details.
-
- 27 Jul, 2016 2 commits
- 28 Jun, 2016 1 commit
-
-
detlevschwabe authored
* Adding condition compiler symbol to support .NET 3.5
-
- 23 Jun, 2016 1 commit
-
-
Jon Skeet authored
This isn't useful to most users, but can be handy in advanced use cases, as requested in #1465.
-
- 29 Apr, 2016 1 commit
-
-
Jon Skeet authored
(And likewise ignore the prefix in unpack.) Fixes issue #1459.
-
- 20 Apr, 2016 1 commit
-
-
Jon Skeet authored
(JSON parsing already does the right thing.)
-
- 29 Mar, 2016 1 commit
-
-
alien authored
-
- 18 Mar, 2016 1 commit
-
-
alien authored
Conflicts: csharp/src/Google.Protobuf/JsonFormatter.cs
-
- 07 Mar, 2016 1 commit
-
-
avgweb authored
-
- 04 Feb, 2016 1 commit
-
-
Jon Skeet authored
(Generated code changes in next commit.)
-
- 20 Jan, 2016 1 commit
-
-
Jon Skeet authored
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.
-
- 15 Jan, 2016 3 commits
- 13 Jan, 2016 1 commit
-
-
Jon Skeet authored
This fixes issue #933, effectively.
-
- 06 Jan, 2016 1 commit
-
-
Jon Skeet authored
This involves quoting timestamp/duration/field-mask values, even when they're not in fields. It's better for consistency. Fixes issue #1097.
-
- 15 Dec, 2015 1 commit
-
-
Jon Skeet authored
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.
-
- 02 Dec, 2015 2 commits
-
-
Jon Skeet authored
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...
-
Jon Skeet authored
-
- 22 Nov, 2015 1 commit
-
-
Jon Skeet authored
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.
-
- 09 Nov, 2015 1 commit
-
-
Jon Skeet authored
-
- 03 Nov, 2015 1 commit
-
-
Jon Skeet authored
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.
-
- 01 Oct, 2015 1 commit
-
-
Jon Skeet authored
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.
-
- 08 Aug, 2015 1 commit
-
-
Jon Skeet authored
-
- 04 Aug, 2015 2 commits
- 03 Aug, 2015 4 commits
-
-
Jon Skeet authored
-
Jon Skeet authored
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.
-
Jon Skeet authored
-
Jon Skeet authored
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.
-
- 31 Jul, 2015 1 commit
-
-
Jon Skeet authored
-
- 30 Jul, 2015 1 commit
-
-
Jon Skeet authored
Rename ThrowHelper to Preconditions and make it public - we'll want to use 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.
-
- 22 Jul, 2015 1 commit
-
-
Jon Skeet authored
I think Jan was actually suggesting keeping both, but that feels redundant to me. The test diff is misleading here IMO, because I wouldn't expect real code using reflection to use several accessors one after another like this, unless it was within a loop. Evidence to the contrary would be welcome :) This change also incidentally goes part way to fixing the issue of the JSON formatter not writing out the fields in field number order - with this change, it does except for oneofs, which we can fix in a follow-up change. I haven't actually added a test with a message with fields deliberately out of order - I'm happy to do so though. It feels like it would make sense to be in google/src/protobuf, but it's not entirely clear what the rules of engagement are for adding new messages there. (unittest_proto3.proto?)
-