New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Integrate changes from upstream/master #536
Integrate changes from upstream/master #536
Conversation
Add the clang annotations to the objc library and generated code to help with Swift bridging and compiler checks.
Add nonnull/nullable/null_resettable markup to ObjC library.
Update upb to fix two bugs in the Ruby library.
We found a Contributor License Agreement for you (the sender of this pull request) and all commit authors, but as best as we can tell these commits were authored by someone else. If that's the case, please add them to this pull request and have them confirm that they're okay with these commits being contributed to Google. If we're mistaken and you did author these commits, just reply here to confirm. |
@jskeet FYI |
Are you going to merge this once it's finished checking, or are you after a review from me? I'll start looking at the other Travis issues... |
Hm, strange error. But at least appveyor has actually started the build and came up with some results. |
Please merge if you agree. |
I don't honestly know enough about Appveyor to have much idea - but I'll take your word for it that it makes things better. I think the Travis failures are due to my wire_format.h change, and possibly the lack of regenerating the descriptor protos. Will fix the wire_format one now, rebase from this, and see whether the freeze PR gets better... |
Integrate changes from upstream/master
Well, appveyor is like travis, but it runs the build on Windows. And it's probably good idea to have a way to check that the build of libprotoc and libprotobuf works alright on Windows as C# cares about Windows support more than the other languages. |
…rs#536) As part of the recent protobuf optimization work, we started generating Unmarshal and Marshal methods on generated messages. These were done to support the table-driven implementation within the proto package. We are renaming Marshal as XXX_Marshal and Unmarshal as XXX_Unmarshal to make it clear that users are not supposed to call these directly. There are several reasons for the rename: * The Marshal method assumes that deterministic is the only option we would ever support for protos, and is not very forward compatible. * The presence of a deterministic boolean is confusing for users, where many set it without considering whether it is necessary. * The Unmarshal method has a slightly different semantic than the previously documented proto.Unmarshaler interface. The documented Unmarshal specifies that Reset is called, while the new method does no such thing. The semantic difference warrants a rename of the method. * Some users in the Go community depend on these methods not being generated by default. Fixes protocolbuffers#530
Two small spelling fixes.
Merge upstream/master. The changes seem orthogonal to C# efforts, so this shouldn't harm us at all.
Main reason to do this is to update appveyor.yml, which is broken in csharp-experimental, but works fine in master (appveyor gives us continous build of C++ under windows, so it's pretty useful to have this working).