| Commit message (Collapse) | Author | Age |
|---|
| |\ |
|
| | | |
|
| |/ |
|
| |
|
|
|
|
|
|
| |
* Fix setup.py for windows build.
* Bump version number to 3.5.2
* Cat the test-suite.log on errors for presubits
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
platform (#1727)
Move to dotnet cli for building, and .NET Core (netstandard1.0) as target platform
This also updates the version number to 3.0.0-beta4
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
| |
(Generated code changes in next commit.)
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
This fixes issue #933, effectively.
|
| | |
|
| |
|
|
| |
Biting off just this bit first as I don't need the changes from a previous PR for this part.
|
| | |
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
| |
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.)
|
| |
|
|
|
|
| |
- 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.
|
| |
|
|
| |
the future.
|
| | |
|
| | |
|
| |
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
Instead, introduce GeneratedCodeInfo which passes in what we need, and adjust the codegen to take account of this.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
We'll see what I've missed when CI fails...
|
Adam Cozzette
Jisi Liu
Cameron Taggart
Paul Yang
Jan Tattermusch
Jon Skeet
Jon Skeet