3.20.x #2
Open
3.20.x #2
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Change toolchain artifact name patterns
They never were needed below file, and they really are specific to two high level case, so don't pass them every where else.
The other generation options never were in the Options structure and ImportWriter was the only thing that needed some the non validation options and it already required directly passing the options. So refine Options to just be validation options and bundle all the File related generation options into a new FileGenerator specific GenerationOptions.
This version defaults all the options, so folks don't have to pass it. Since Options never had a PROTOC_EXPORT, it isn't immediately clear how well the existing api worked for any shared lib cases, so this should give a simpler api for the basic usage (if anyone wants to use it).
Add bazel rules to do Kotlin mvn exports
Overdue followup to #7173 Since all the files are at the same level as the runtime headers, there is no need for things to be framework based imports, they should all just work like the other headers do. - Directly generate the bundled header imports into the preamble section when generating for a bundled proto. - Update the preamble generation to skip the CPP wrapper when generating for a bundled proto file. - Regenerate the WKTs. - Update GPBProtocolBuffer.h/GPBWellKnownTypes.h to also skip the CPP wrapping. GPB_USE_PROTOBUF_FRAMEWORK_IMPORTS in the podspec and non bundled files still has to exist because that comes into play for those files to find the runtime headers.
Suppress warning for intentional circular require
PROTOBUF_SYNC_PIPER
Thanks to @sbenzaquen for this fix.
Integrate from Piper for C++, Java, and Python
Fix a few issues with the Emacs mode definition. First, in 1ab7789 (2021-10-13, Emacs: Protobuf mode should be derived from prog-mode) we made `protobuf-mode' a derived mode of `prog-mode' using the `define-derived-mode' macro[1]. However, the definition body was not updated accordingly. So in this commit, we: - Remove the superfluous `(interactive)' form; - Remove the unnecessary call of `kill-all-local-variables', which is already handled by `define-derived-mode' and could cause a few issues, for example, it prevents `prog-mode-hook' from being run; - Remove forms that set `major-mode' and `mode-name', which are automatically set to the first and third arguments respectively; - Remove forms that set key map, syntax table, and abbrev table, which are already handled automatically; - Do not run `protobuf-mode-hook' explicitly in the body. It is already arranged to be run after the body. Second, the call to `c-make-emacs-variables-local' is removed. It is called inside `c-init-language-vars' already. Calling it again should do no harm now, but to be future-proof it might be better to just remove it. Finally, we move the `c-update-modeline' form to the :after-hook argument to ensure it is run at the very end, so that the mode line will reflect all user customizations done in various mode hooks. Similarly, we run `c-mode-common-hook' also at the very end to leave a place for user customizations (for example, set `imenu-generic-expression' in `c-mode-common-hook'). [1] https://www.gnu.org/software/emacs/manual/html_node/elisp/Derived-Modes.html Re: #7316 Re: #9076
PROTOBUF_SYNC_PIPER
…ders. Swift importing ObjC drops methods/properties if the type is only a forward declaration since the type is incomplete. Historically the generator has always use forward declarations to reduce how much will have rebuild when a proto file does change; but that puts it at odds with Swift. If ObjC Protos end up spanning Swift modules, the Swift import behavior could become a problem; so this option provides a control for the behavior. The current behavior is to continue forward declarations, but eventually the default will be changed. Generate the WKTs using imports instead of forward decls.
Integrate from Piper for C++, Java, and Python
The JRuby test runs appear to be fetching the util package from Maven Central because it is not being installed locally. This causes the tests to fail when we upgrade to a new version that has not yet been published to Maven Central. This commit fixes the problem by locally installing all the protobuf packages, not just util.
We tried increasing it to 3.10, but that turned out to be too high since gRPC still supports 3.5.1.
Fix codespell errors
Use local protoc artifacts
* Porting java cleanup * Update changelog * Fix absl usage * Extension patch * Remove extra allocations
3.20.x 202209291741
3.20.x 202209292242
We are seeing failures in `brew uninstall protobuf` due to no package. Change this to a force install to avoid the error.
Force uninstall protobuf in python macos builds
Upgrade kokoro to Xcode 14
* Fix mac builds Allow xcode version 14.x as we upgraded to it #10733 * Upgrading simulator version Co-authored-by: Mike Kruskal <[email protected]>
3.20.x No longer define no_threadlocal on OpenBSD
pin tox to v3.27.1 (to fix kokoro)
fix kokoro git config
Update iOS version
Pin to bundler with ruby 2.5 support
* Fix mutability bug in Java proto lite: sub-messages inside of oneofs were not being set as immutable. This would allow code to get a builder for a sub-message and modify the original (supposedly immutable) copy. PiperOrigin-RevId: 511598810 * Add casts to make protobuf compatible with Java 1.8 runtime. Fix for: #11393 PiperOrigin-RevId: 511807920 * Update Makefile.am --------- Co-authored-by: Protobuf Team Bot <[email protected]>
Ruby 3.20.x is no longer supported and the tests were flaky
Remove ruby support
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.