| 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.
|
| |
|
|
|
|
|
|
|
| |
The SampleEnumMethod method was previously only called via
reflection, so the Unity linker thought it could be removed. Ditto
the parameterless constructor in ReflectionHelper.
This PR should avoid that issue, reducing the work needed by
customers to use Google.Protobuf from Unity.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
For oneofs, to get the case, we need to call the property that
returns the enum value. We really want it as an int, and modern
runtimes allow us to create a delegate which returns an int from the
method. (I suspect that the MS runtime has always allowed that.)
Old versions of Mono (e.g. used by Unity3d) don't allow that, so we
have to convert the enum value to an int via boxing. It's ugly, but
it should work.
|
| | |
|
| |
|
|
|
|
| |
This should work on Unity, Mono and .NET 3.5 as far as I'm aware.
It won't work on platforms where reflection itself is prohibited,
but that's a non-starter basically.
|
| | |
|
| |
|
|
| |
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
Jon Skeet