aboutsummaryrefslogtreecommitdiff
path: root/csharp
Commit message (Collapse)AuthorAgeFilesLines
* Generated code changes for previous commit (basically ↵Jon Skeet2015-11-2221-22/+22
| | | | InternalBuildGeneratedFileFrom => FromGeneratedCode)
* Tidy up reflection in advance of attempting to implement DynamicMessage.Jon Skeet2015-11-229-224/+187
| | | | | | | | | 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.
* Added the type registry in advance of implementing Any support.Jon Skeet2015-11-214-0/+279
| | | | Biting off just this bit first as I don't need the changes from a previous PR for this part.
* Merge pull request #988 from gabikliot/CSharp-SampleUsage-Big-FixJan Tattermusch2015-11-191-2/+5
|\ | | | | Fixed a bug in CSharp SampleUsage.
| * Removed redundant comment.Gabriel Kliot2015-11-191-1/+0
| |
| * Fixed a bug in CSharp SampleUsage.Gabriel Kliot2015-11-181-1/+5
| |
* | Finished an implementation commentJon Skeet2015-11-191-1/+3
| |
* | Generated code from previous commit.Jon Skeet2015-11-1920-105/+107
| |
* | Introduce a Parser property into MessageDescriptor, and populate it from ↵Jon Skeet2015-11-194-16/+134
| | | | | | | | | | | | 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.
* | Generated code changes and manual changes for previous commit.Jon Skeet2015-11-0927-467/+441
|/
* Generated code for previous commit.Jon Skeet2015-11-0610-0/+115
|
* Merge pull request #941 from jskeet/recursion-limitJan Tattermusch2015-11-056-15/+135
|\ | | | | Add recursion limit handling to JSON parsing.
| * Reimplement JSON recursion by detecting the depth in the tokenizer.Jon Skeet2015-11-054-34/+124
| | | | | | | | Added a TODO around a possible change to the tokenizer API, changing PushBack(token) into just Rewind() or something similar.
| * Add recursion limit handling to JSON parsing.Jon Skeet2015-11-043-44/+74
| | | | | | | | Fixes issue #932.
* | Merge pull request #940 from jskeet/json-namesJon Skeet2015-11-052-6/+16
|\ \ | | | | | | Move the creation of the "fields by JSON name" dictionary to the descriptor
| * | Move the creation of the "fields by JSON name" dictionary to the descriptor.Jon Skeet2015-11-042-6/+16
| |/
* / Created a new exception for JSON failures.Jon Skeet2015-11-057-40/+110
|/ | | | | | 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.
* Implement JSON parsing in C#.Jon Skeet2015-11-0316-22/+2910
| | | | | | | | | | 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.
* Make BytesString.Unsafe internal (which it should have been all along)Jon Skeet2015-11-021-3/+3
|
* Fix clearing wrapper type fields with reflection.Jon Skeet2015-10-303-2/+12
| | | | The nullable value type fields already worked, but the use of the CLR property concealed the difference between string and StringWrapper fields.
* Generated code for previous commit (oneof case contributing to hash code and ↵Jon Skeet2015-10-246-81/+133
| | | | equality).
* Include the oneof-case in equality and hash code generated code.Jon Skeet2015-10-241-0/+10
| | | | The included C# test will fail until the regenerated code is used, which is in the next commit.
* Merge pull request #846 from jskeet/tostringJon Skeet2015-10-075-115/+203
|\ | | | | Support ToString in RepeatedField and MapField.
| * Support ToString in RepeatedField and MapField.Jon Skeet2015-10-015-115/+203
| | | | | | | | | | | | 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.
* | Generated code from previous commit.Jon Skeet2015-10-0119-0/+1945
|/
* Fix typo in oneof case enum commentJon Skeet2015-09-305-9/+9
|
* Generated code changes for previous commit.Jon Skeet2015-09-2919-34/+34
|
* Generated code for previous commitJon Skeet2015-09-2919-0/+62
|
* Added documentation to generated code.Jon Skeet2015-09-292-2/+2
| | | | | | | | | | | There are now summaries for: - The Types nested class (which holds nested types) - The file descriptor class for each proto - The enum generated for each oneof (Also fixed two typos.) Generated code in next commit.
* Merge pull request #785 from jskeet/csharp-directoriesJan Tattermusch2015-09-2320-749/+1043
|\ | | | | Generate C# directory hierarchy with new option
| * Regenerated code. Most changes are whitespace, removing trailing spaces.Jon Skeet2015-09-0119-741/+1033
| | | | | | | | Other changes are due to the well-known types changing without us regenerating.
| * Generate a directory hierarchy based on namespace (C#)Jon Skeet2015-09-011-8/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | This introduces a new C# option, base_namespace. If the option is not specified, the behaviour is as before: no directories are generated. If the option *is* specified, all C# namespaces must be relative to the base namespace, and the directories are generated relative to that namespace. Example: - Any.proto declares csharp_namespace = "Google.Protobuf.WellKnownTypes" - We build with --csharp_out=Google.Protobuf --csharp_opt=base_namespace=Google.Protobuf - The Any.cs file is generated in Google.Protobuf/WellKnownTypes (where it currently lives) We need a change to descriptor.proto before this will all work (it wasn't in the right C# namespace) but that needs the other descriptors to be regenerated too. See next commit...
* | Pack/Unpack implementation for Any.Jon Skeet2015-09-045-0/+149
|/ | | | | 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.)
* Update README.md for C#Jan Tattermusch2015-08-261-7/+12
|
* Merge pull request #738 from jtattermusch/include_descriptor_protoJon Skeet2015-08-261-0/+1
|\ | | | | Include descriptor.proto in nuget package
| * include descriptor.proto in nuget packageJan Tattermusch2015-08-251-0/+1
| |
* | Remove extraneous TODOJon Skeet2015-08-251-1/+0
| |
* | Change where we rename Descriptor.cs to DescriptorProtoFile.cs.Jon Skeet2015-08-253-117/+115
|/ | | | | | | | | | | We now do this in protoc instead of the generation simpler. Benefits: - Generation script is simpler - Detection is simpler as we now only need to care about one filename - The embedded descriptor knows itself as "google/protobuf/descriptor.proto" avoiding dependency issues This PR also makes the "invalid dependency" exception clearer in terms of expected and actual dependencies.
* fix type initialization problem with FileDescriptorJan Tattermusch2015-08-141-148/+175
|
* add a failing descriptor testJan Tattermusch2015-08-141-0/+7
|
* remove duplicate test caseJan Tattermusch2015-08-141-1/+0
|
* Allow public access to descriptor.proto as a dependency.Jon Skeet2015-08-131-0/+15
| | | | | With this in place, generating APIs on github.com/google/googleapis works - previously annotations.proto failed. Currently there's no access to the annotations (stored as extensions) but we could potentially expose those at a later date.
* More TODOs done.Jon Skeet2015-08-107-126/+168
| | | | | | - 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.
* Merge pull request #701 from jskeet/map-viewsJon Skeet2015-08-102-4/+180
|\ | | | | Implement Keys and Values as views in MapField
| * Fix parameter name in exception.Jon Skeet2015-08-101-1/+1
| |
| * Implement ICollection.CopyTo (using Array) for MapField views.Jon Skeet2015-08-102-1/+26
| |
| * Implement Keys and Values as viewsJon Skeet2015-08-082-4/+155
| |
* | Make FieldDescriptor.IsPacked work appropriately.Jon Skeet2015-08-083-4/+18
|/ | | | | 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.
* Address review comments.Jon Skeet2015-08-081-2/+0
|
* Remove reference to generic types within XML comment.Jon Skeet2015-08-081-2/+2
| | | | Visual Studio is happy with it, but Mono isn't :(