1. 30 Oct, 2019 1 commit
  2. 23 Aug, 2019 8 commits
  3. 03 May, 2019 1 commit
    • Sydney Acksman's avatar
      C# Proto2 feature : Extensions (#5350) · 9e89b6e7
      Sydney Acksman authored
      * Compiler changes (extensions)
      
      * Generated changes (extensions)
      
      * Library changes (extensions)
      
      * Adjusted a summary to indicate ContainingType can be null for extensions
      
      * Compiler changes (custom option review + access level review)
      
      * Generated code changes (custom options + access review)
      
      * Library changes (custom options + access review)
      
      * Support C# 6 with library changes
      
      * Access HasValue by property
      
      * Set access level of all extension classes to internal (revert in next PR)
      
      * Added null checks to custom options
      
      * Rebase on master and regenerate Conformance
      
      * Removed second dictionary from ExtensionSet
      
      * Rebased compiler changes
      
      * Rebased generated code changes
      
      * Rebased library changes + review changes
      
      * Add more safety checks to extension accessors
      
      * Remove instances where extension sets were unnecessarily allocated
      
      * Remove cleared items from sets
      Empty sets are now made null
      IExtensionMessage -> IExtendableMessage
      
      * Remove dead code from IExtensionValue impls
      
      * Clean both repeated and single value extensions
      
      * Add GetOrRegister method for repeated fields and allow clearing repeated extensions
      
      * Add type safe ClearExtension methods, remove non-generic IExtendableMessage interface.
      
      * Simplify ExtensionSet.TryMergeFieldFrom
      
      * Rebase on master to resolve conflicts
      
      * Fix Makefile.am
      
      * Add ObjectIntPair to Makefile.am
      9e89b6e7
  4. 21 Feb, 2019 1 commit
  5. 22 Sep, 2018 4 commits
    • Jon Skeet's avatar
      47d33e75
    • Jon Skeet's avatar
      Simplify descriptor tests · 1376ee4e
      Jon Skeet authored
      Rather than converting the proto to a ByteString again, use the
      existing SerializedData property.
      1376ee4e
    • Jon Skeet's avatar
    • Jon Skeet's avatar
      Provide simple access to descriptor declarations in C# · 17119990
      Jon Skeet authored
      This is primarily for access to comments, which would be expected to be available in a protoc plugin.
      
      The implementation has two fiddly aspects:
      
      - We use a Lazy<T> to avoid building the map before cross-linking. An alternative would be to crosslink at the end of the constructor, and remove the calls to CrossLink elsewhere. This would be generally better IMO, but deviate from the Java code.
      - The casts to IReadOnlyList<DescriptorBase> are unfortunate. They'll always work, because these lists are always ReadOnlyCollection<T> for a descriptor type... but we can't use IList<DescriptorBase> as that's not covariant, and it's annoyingly fiddly to change the field to be of type ReadOnlyCollection<T>.
      17119990
  6. 10 Sep, 2018 1 commit
  7. 20 Aug, 2018 1 commit
  8. 19 Dec, 2017 1 commit
  9. 12 Nov, 2017 1 commit
  10. 27 Jan, 2017 1 commit
  11. 19 Jan, 2017 1 commit
    • Jon Skeet's avatar
      Support custom options in C# · 047575f2
      Jon Skeet authored
      This consists of:
      - Changing the codegen for the fixed set of options protos, to parse unknown fields instead of skipping them
      - Add a new CustomOptions type in the C# support library
      - Expose CustomOptions properties from the immutable proto wrappers in the support library
      
      Only single-value options are currently supported, and fetching options values requires getting the type right
      and knowing the field number. Both of these can be addressed at a later time.
      
      Fixes #2143, at least as a first pass.
      047575f2
  12. 20 Apr, 2016 1 commit
  13. 22 Nov, 2015 1 commit
    • Jon Skeet's avatar
      Tidy up reflection in advance of attempting to implement DynamicMessage. · 72ec3367
      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.
      72ec3367
  14. 21 Nov, 2015 1 commit
  15. 19 Nov, 2015 1 commit
  16. 09 Nov, 2015 1 commit
  17. 14 Aug, 2015 1 commit
  18. 08 Aug, 2015 1 commit
    • Jon Skeet's avatar
      Make FieldDescriptor.IsPacked work appropriately. · 547d8e82
      Jon Skeet authored
      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.
      547d8e82
  19. 31 Jul, 2015 1 commit
  20. 25 Jul, 2015 1 commit
  21. 22 Jul, 2015 3 commits
    • Jon Skeet's avatar
      Implemented Jan's suggestion of FieldCollection, replacing FieldAccessorCollection. · c1c6b2d0
      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?)
      c1c6b2d0
    • Jon Skeet's avatar
      Added newlines · 5e0cfc9a
      Jon Skeet authored
      5e0cfc9a
    • Jon Skeet's avatar
      First pass at making field access simpler. · 20bf6a56
      Jon Skeet authored
      This is definitely not ready to ship - I'm "troubled" by the disconnect between a list of fields in declaration order, and a mapping of field accessors by field number/name. Discussion required, but I find that easier when we've got code to look at :)
      20bf6a56
  22. 21 Jul, 2015 1 commit
    • Jon Skeet's avatar
      Revamp to reflection. · 53c399a1
      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.
      53c399a1
  23. 17 Jul, 2015 1 commit