| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With this fix, Unity using IL2CPP should work with one of two
approaches:
- Call `FileDescriptor.ForceReflectionInitialization<T>` for every
enum present in generated code (including oneof case enums)
- Ensure that IL2CPP uses the same code for int and any int-based
enums
The former approach is likely to be simpler, unless IL2CPP changes
its default behavior. We *could* potentially generate the code
automatically, but that makes me slightly uncomfortable in terms of
generating code that's only relevant in one specific scenario. It
would be reasonably easy to write a tool (separate from protoc) to
generate the code required for any specific set of assemblies, so
that Unity users can include it in their application. We can always
decide to change to generate it automatically later.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This check adds a few constraints on the way to build a project when we have
a proto file which imports another one. In particular, on projects which
build both C# and Java, it's easy to end up with exceptions like
Expected: included.proto but was src/main/protobuf/included.proto
A user may work around this issue, but it may add unnecessary constraints
on the layout of the project.
According to https://github.com/google/protobuf/commit/f3504cf3b1d456a843e8242fdee9ba0bf2991dc1#diff-ecb0b909ed572381a1c8d1994f09a948R309
it has already been considered to get rid of this check, for
similar considerations, and because it doesn't exist in the Java code
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
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.
|
| | |
|
| |
|
|
| |
the future.
|
| | |
|
| |
|
|
| |
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 :)
|
| |
|
|
| |
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...
|
Jon Skeet
Guillaume Turri
Jan Tattermusch