- 19 Dec, 2017 1 commit
-
-
Jisi Liu authored
-
- 30 Nov, 2017 1 commit
-
-
Jie Luo authored
-
- 02 Nov, 2017 1 commit
-
-
Jisi Liu authored
-
- 14 Sep, 2017 1 commit
-
-
Jisi Liu authored
-
- 12 Sep, 2017 1 commit
-
-
Jan Tattermusch authored
-
- 05 Sep, 2017 1 commit
-
-
Jan Tattermusch authored
-
- 02 Aug, 2017 1 commit
-
-
Jisi Liu authored
-
- 13 Jul, 2017 1 commit
-
-
Jon Skeet authored
-
- 24 May, 2017 2 commits
-
-
Jon Skeet authored
-
Jon Skeet authored
This has one important packaging change: the netstandard version now depends (implicitly) on netstandard1.6.1 rather than on individual packages. This is the preferred style of dependency, and shouldn't affect any users - see http://stackoverflow.com/questions/42946951 for details. The tests are still NUnit, but NUnit doesn't support "dotnet test" yet; the test project is now an executable using NUnitLite. (When NUnit supports dotnet test, we can adapt to it.) Note that the project will now only work in Visual Studio 2017 (and Visual Studio Code, and from the command line with the .NET Core 1.0.0 SDK); Visual Studio 2015 does *not* support this project file format.
-
- 14 Jul, 2016 2 commits
- 20 Apr, 2016 1 commit
-
-
Jon Skeet authored
Overview of changes: - A new C#-specific command-line option, legacy_enum_values to revert to the old behavior - When legacy_enum_values isn't specified, we strip the enum name as a prefix, and PascalCase the value name - A new attribute within the C# code so that we can always tell the original in-proto name Regenerating the C# code with legacy_enum_values leads to code which still compiles and works - but there's more still to do.
-
- 09 Feb, 2016 1 commit
-
-
Jan Tattermusch authored
-
- 04 Feb, 2016 2 commits
-
-
Jon Skeet authored
(Generated code changes in next commit.)
-
Jon Skeet authored
Recently, descriptor.proto gained a GeneratedCodeInfo message, which means the generated code conflicts with our type. Unfortunately this affects codegen as well, although this is a part of the public API which is very unlikely to affect hand-written code. 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.
-
- 13 Jan, 2016 1 commit
-
-
Jon Skeet authored
This fixes issue #933, effectively.
-
- 17 Dec, 2015 1 commit
-
-
Jan Tattermusch authored
-
- 21 Nov, 2015 1 commit
-
-
Jon Skeet authored
Biting off just this bit first as I don't need the changes from a previous PR for this part.
-
- 09 Nov, 2015 1 commit
-
-
Jon Skeet authored
-
- 05 Nov, 2015 1 commit
-
-
Jon Skeet authored
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.
-
- 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.
-
- 04 Sep, 2015 1 commit
-
-
Jon Skeet authored
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.)
-
- 10 Aug, 2015 1 commit
-
-
Jon Skeet authored
- 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.
-
- 04 Aug, 2015 1 commit
-
-
Jon Skeet authored
-
- 02 Aug, 2015 2 commits
-
-
Jan Tattermusch authored
-
Jan Tattermusch authored
-
- 31 Jul, 2015 1 commit
-
-
Jon Skeet authored
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.
-
- 30 Jul, 2015 2 commits
-
-
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.
-
Jan Tattermusch authored
-
- 27 Jul, 2015 1 commit
-
-
Jon Skeet authored
This requires .NET 4.5, and there are a few compatibility changes required around reflection. Creating a PR from this to see how our CI systems handle it. Will want to add more documentation, validation and probably tests before merging. This is in aid of issue #590.
-
- 22 Jul, 2015 1 commit
-
-
Jon Skeet authored
Instead, introduce GeneratedCodeInfo which passes in what we need, and adjust the codegen to take account of this.
-
- 21 Jul, 2015 1 commit
-
-
Jon Skeet authored
Changes in brief: 1. Descriptor is now the entry point for all reflection. 2. IReflectedMessage has gone; there's now a Descriptor property in IMessage, which is explicitly implemented (due to the static property). 3. FieldAccessorTable has gone away 4. IFieldAccessor and OneofFieldAccessor still exist; we *could* put the functionality straight into FieldDescriptor and OneofDescriptor... I'm unsure about that. 5. There's a temporary property MessageDescriptor.FieldAccessorsByFieldNumber to make the test changes small - we probably want this to go away 6. Discovery for delegates is now via attributes applied to properties and the Clear method of a oneof I'm happy with 1-3. 4 I'm unsure about - feedback welcome. 5 will go away 6 I'm unsure about, both in design and implementation. Should we have a ProtobufMessageAttribute too? Should we find all the relevant attributes in MessageDescriptor and pass them down, to avoid an O(N^2) scenario? Generated code changes coming in the next commit.
-
- 17 Jul, 2015 1 commit
-
-
Jon Skeet authored
We'll see what I've missed when CI fails...
-
- 16 Jul, 2015 1 commit
-
-
Jan Tattermusch authored
-
- 14 Jul, 2015 3 commits
-
-
Jon Skeet authored
This involves: - Specifying a namespace in each proto (including ones we'd previously missed) - Updating the generation script - Changing codegen to implement IReflectedMessage.Fields explicitly (a good thing anyway) - Changing reflection tests to take account of the explicit interface implementation Non-generated code in this commit; generated code to follow
-
Jon Skeet authored
Change the C# namespace in descriptor.proto to Google.Protobuf.Reflection. This then means changing where the generated code lives, which means updating the project file... It also involves regenerating the C++ - which has updated the well-known types as well, for no terribly obvious reason...
-
Jon Skeet authored
- Move types into Google.Protobuf.Reflection - Change codegen to reflect that in generated types Generated code changes coming in part 2
-
- 10 Jul, 2015 1 commit
-
-
Jan Tattermusch authored
-