[pull] main from apple:main #2
Open
Conversation
This file contains hidden or 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
Move new errors to extendable struct-based SwiftProtobufError
maybe squash
Add back removed public API
Change API version back to 2
Fix handling of map fields inheriting delimited encoding
Using protobuf commit 40ffd46cec1291e1320e46a134c47dd23a74ff43.
This aligns with what happened in protocolbuffers/protobuf#16448.
…r.nextInt32`. (#1859) Thanks to a heterogeneous comparison operator on `BinaryInteger`, the expression `someUInt64 < 1 &<< 32` was compiling incorrectly on 32-bit architectures, because the right-hand side was being inferred as `Int` instead of `UInt64`. And on a 32-bit system, `1 &<< 32` is zero. Fixes #1858.
On platforms targeting Swift 6.2 and later this allows a `RawSpan` in lieu of `SwiftProtobufContiguousBytes`-conforming type when creating or merging a protobuf message. This will improve memory usage by reducing allocations, for example when parsing a large document that includes protobuf messages as part of its binary. Unlike the internal `_merge` function, this does not expose unsafe API while retaining its benefits. - I decided to make a twin declaration of the initializer and `merge` function instead of conforming `RawSpan` to `SwiftProtobufContiguousTypes`, because - a) `RawSpan` is not mutable, and - b) `Span` types are non-owning and cannot conform to initializers. - I used the conditional compilation block and `@available` directive per ~~analogy to [this implementation in SwiftNIO](https://github.com/apple/swift-nio/blob/main/Sources/NIOCore/ByteBuffer-core.swift#L1066)~~ [docs](https://developer.apple.com/documentation/swift/rawspan). --------- Co-authored-by: Franz Busch <[email protected]>
- Call out clicking edit. - Ensure the protoc release doesn't get counted as the "latest" for the repo.
The `Span` support was a _minor_ bump, so left that out of the previous release so folks would get the assertion fix if they were only accepting bug fixes.
See swiftlang/github-workflows#167 for additional context This approach aligns with security best practices, as detailed in the following documentation: - https://github.com/ossf/scorecard/blob/main/docs/checks.md#token-permissions - https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax#defining-access-for-the-github_token-scopes - https://openssf.org/blog/2024/08/12/mitigating-attack-vectors-in-github-workflows/ The default GITHUB_TOKEN permissions are defined at the repository level. This PR modifies the workflow-level overrides to conform to OpenSSF best practices -> defense in depth. Allow me to quote OpenSSF: https://github.com/ossf/scorecard/blob/main/docs/checks.md#token-permissions > The highest score is awarded when the permissions definitions in each workflow's yaml file are set as read-only at the top level and the required write permissions are declared at the run-level.” > Remediation steps > - Set top-level permissions as read-all or contents: read as described in GitHub's documentation. > - Set any required write permissions at the job-level. Only set the permissions required for that job; do not set permissions: write-all at the job level. Compare to the LLVM project: Top-level: contents read, e.g. https://github.com/swiftlang/llvm-project/blob/next/.github/workflows/build-ci-container-windows.yml#L3-L4 -> this makes it future-proof Job-level: Allow write permissions as needed, e.g. https://github.com/swiftlang/llvm-project/blob/next/.github/workflows/build-ci-container-windows.yml#L53-L58 Signed-off-by: Melissa Kilby <[email protected]>
…1866) Given a oneof field with ~600 options, the generated traverse function will fail to compile because swift is unable to check the switch is exhaustive in reasonable time. See #1856 This PR follows similar logic to #904 which allows switch statements to be broken up into multiple switch statements (using a `default: break` case). Instead of hardcoding 500, I've added a new GeneratorOption to support setting the "maxCasesInSwitch" which allows the same number to be used in `EnumGenerator` and `OneofGenerator` and allows clients to set this number to whatever suits them based on Swift version or other considerations. This number could also be set to something very high to effectively turn off the feature. The second commit adds tests, I asked claude to help out with this part so please help me in double checking those tests. I was able to run tests successfully locally.
## Motivation In a recent addition, we included changes to provide `protoc` as a binary target from the official releases from the upstream `protobuf` repository. While this solved one of the largest issues in our ecosystem where folks currently needed to install `protoc` through a system package manager, it also introduced another set of problems that binary targets bring with them. ## Modifications This PR adds `protobuf` and `abseil-cpp` as a submodule to this project and includes a new target that builds both together from source. It includes the minimal set of files from both to successfully build `protoc` and also passes the right compiler and linker flags to build those warning free. ## Result We are no longer using a binary target for `protoc` but instead build it from source which alleviates the problems that we introduced with the binary target.
## Motivation In my recent work to build `protoc` from source I mistakenly disabled warnings by using unsafe flags. Unsafe flags make packages essentially unusable. ## Modifications Disable the warnings by using the new warning control settings introduced in 6.2 instead. ## Result Fixes #1881
It appears that on macOS when building with Xcode the latest changes have resulted in a error when resolving `swift-protobuf` reported in #1884. This PR ignores the abseil privacy manifest which should fix the issue
No longer need to force it on 6+ since the binary built in the package.
- Don't override the `PROTOC` value when running tests, let the in tree one be used. - For conformance tests, only build the runner in the protobuf checkout (no need to force a `protoc` build also) - Move the protobuf conformance runner build and the conformance tests to be after all the other steps, might as well let everything else finish first to catch issues before waiting on another protobuf to build. - Turn off the tests on 5.10 that need protoc – `[email protected]` doesn't include the `protoc` target, so skip the tests there that need it.
This will give early warning again instead of trigger after we do an update.
- Repo stopped using "@testable import" a while ago. - Update a bug reference.
As of Xcode 26.0.1 atleast it seems to be passing.
Motivation: The generated code has explicit returns for computed properties in a number of places. Modifications: - Removed explicit 'return' where possible Result: Generated code is ever-so-slightly smaller
Since there are multiple commands happening, it wasn't actually making the `make` fail when there were changes found. Solve this by using a temp file to hold all the diffs, and check if it has anything at the end to do the reporting.
The logic for this comes from the C++ code: https://github.com/protocolbuffers/protobuf/blob/195da42b90bd39aa8c0b6551188fccf77a83f506/src/google/protobuf/io/coded_stream.h#L1754-L1826 I've always thought Swift didn't have a way to get to the optimal instructions, but I was wrong, it has all the building blocks needed. Looking at new code in godbolt, in `-O`, without or without the arithmetic overflow protection, the code is the same (tiny), but by turning off the arithmetic overflow checks, we also keep the debug code a bit smaller.
- Have the `Makefile` provide better messaging in the conformance runners isn't found. - Have `build.yml` run the conformance tests as it is in the protobuf submodule. - Revise the cron based conformance run to be a protobuf HEAD run, so it happens on every PR and still happens on a cron as an early signal for when something might need attention.
Both sides are the same. This seems to go back to 3019487 where we didn't catch that they two were now the same.
Using upstream 9e726ed80a5ef377bdc807ec61624158e9663af3
Was needed to just land the upstream proto change that added an enum element that isn't really considered breaking for the runtime.
The additional information doesn't factor into the Swift generation, so no need to regenerate/etc. Used upstream 9a98695003398ef186ca8a9c8ab0feba0595029c.
Update proto files. Using upstream 192cd6631aba683489ae720c5e87f551412d6a9b.
Follow-up to the integration of edition unstable in [commit f955596](f955596) --------- Co-authored-by: Rachel Goldfinger <[email protected]> Co-authored-by: Tony Allevato <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
19 participants
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.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )