Motivation:
When setting the default actor isolation to 'MainActor', generated
protobuf code will fail to compile.
Modifications:
- Add 'nonisolated' to generated declaration
- Add a compile test
Result:
- Resolves https://github.com/apple/swift-protobuf/issues/1797
Motivation:
The recent changes to the build plugin only add import paths to the
SwiftPM entrypoint. The Xcode plugin entrypoint doesn't have appropriate
support to add an import for the WKTs.
Another limitation of the current approach is that users building and
using `protoc` from the pacakge (i.e. `swift build --product protoc`)
won't get the WKT include paths.
This changes takes a different approach by rewriting the entrypoint to
protoc to unconditionally add the WKT include path. This means WKTs work
for the SwiftPM plugin, Xcode plugins, and when using `protoc` directly.
It also obviates the need for downstream pacakges depending on `protoc`
in their plugins (e.g. gRPC) to scan for the include paths in their
plugins.
Modifications:
- Add a new 'main.cc' which does what 'main_no_generators.cc' does but
adds the WKT include path to the invocation.
- Remove 'main_no_generators.cc' and update the vendoring script to
prune it out.
- Revert recent changes to the SwiftPM plugin which scanned for protobuf
sources for the include path
Result:
WKTs work with protoc in more places
When this failed on CI the other day it looked a little odd as the "-"
lines were the ones that were the new state. So flip the order so the
"+" lines are how it should be generated vs. what is currently checked
in to the Reference directory. i.e. - the output becomes "the patch to
apply to reference" instead of the output being what would get applied
to the "generator".
Motivation:
Swift 6.0 has fallen out of our support policy.
Modifications:
- remove Package@swift-6.0.swift
- update various docs and examples
- drop Swift 6.0 from CI
Result:
Swift 6.0 is no longer supported
Fixes#1943 and supersedes #1979.
This PR adds support for well known types in the Swift PM plugin by
either:
- Looking for the types next to the binary when the env variable or a
direct protoc path is specified
- Looking for the source directory of our vendored protobuf repo
Co-authored-by: Thomas Van Lenten <thomasvl@google.com>
In looking at the code coverage on oss-fuzz, I realized the encoding
support never goes down paths related to options being not the default,
so go ahead and allow the existing options extraction to set those also,
so we're running everything possible to help look for bugs.
All but one of the options defaulted to "false", so since the fuzz
options parsing was ensuring the extra bits were zero, it is safe to
just add the option. The one that wasn't zero, we add a new "inverted"
bool so all saved cases remain valid.
This also gave us the change to control "partial" on binary decoding, so
wire that up also.
Lastly, while at it, increase the options logging so it is a little more
complete.
Now that https://github.com/google/oss-fuzz/pull/14342 has landed, we
can properly updated FuzzTesting/Package.swift to also be 6.x based.
This pulls over what @glbrntt's had attempted in #1913 but couldn't be
landed because of issues in 6.0/6.1, but now that we only do fuzz
testing on 6.2+ it is safe.
It also sets the explicit `traits` for SwiftProtobuf since the FieldMask
additions aren't needed.
protobuf: v34.1 (4b0c3aacf0657fbf38253b38918d3358dd4319ec)
abseil: 76bb24329e8bf5f39704eb10d21b9a80befa7c81 tag:20250512.1
This was done by manually running the script and then looking at what
files got removed and added to figure out the Package*.swift changes.
Note: the script doesn't run on Sequoia without edits because it uses
some things in newer versions of python3 than what Apple bundles there.
Also documented a lot more about how/why decisions are made.
Since the current algorithm stop as soon as it has found the first path
to recursion, this still isn't as optimal as possible. A truly optimal
solution would more completely evaluate the graph so there are fewer
places that need to repeat the work.
If `make reference` fails, revert the changes to `Reference/` that did
happen, and then make the PR opened a _Draft_ and add a warning to the
PR message to draw attention to the fact that it is likely incomplete
and the `Package.swift` will need updated.
While at it, mark two other workflows as only for the
apple/swift-protobuf repo so they don't run in forks.
Fixesapple/swift-protobuf#2000.
SwiftPM recursively checks out git submodules during package resolution.
The protobuf and abseil submodules are large C++ repositories, but every
consumer has to pay the cost of fetching them for every checkout because
SwiftPM cannot cache submodules as their bare repositories.
This PR replace protobuf/abseil submodules with vendored sources.
## Commits
1. Add protobuf vendor update automation
3. Remove protobuf and abseil submodule
4. Vendor protobuf and abseil
Reviewers can focus on the first commit; commits 2 and 3 are mechanical.
## Alternative Considered
git subtree was also considered but ruled out: it does not support
selective path filtering across multiple directories (we only need a
subset of files from each repo).
Like last time, only needed to land descriptor updates; which we don't
control and only plugins rely on the information and the plugin api we
expose hides these types of details, but we need to update the proto
file to part newer files.
Maps the default `traits` to preprocessor defines when building the
library.
Tested by swapping the
```swift
#endif
```
for:
```swift
#warning("Defined.")
#else
#error("Not defined.")
#endif
```
And inspecting the output of `pod lib lint` to confirm the `#warning` is
hit and not the `#error`. Fixes#2005
Reorder some of the tests to easily only exclude the ones that need the
Foundation support.
Also bring over some tests that the other class has that weren't done
here.
Adds linkage test to make sure we don't regress importing Foundation.
Also, the `.copy` resources in SwiftPM imports full Foundation, so we
guard that behind Darwin.
Also fixes the last remaining Foundation part, which was
`String.contains`.
## Result
`swift-protobuf` can now be built with `FoundationEssentials` only.
Broke out from #1968
Instead of importing `Foundation` in the `DoubleParser`, we just import
the relevant C library which contains the `strtod` function.
# Motivation
Swift protobuf currently generates exhaustive (aka frozen) enums;
however, in proto3 enums and oneofs are open and it is binary and wire
compatible to add new cases to either.
# Modifications
This PR introduces a new generator option called `EnumGeneration` that
allows developers to add the newly introduced `@nonexhaustive` attribute
to enums. Because adding this attribute is a source breaking change the
default stays the same as it currently is. Additionally, this PR adds
multiple tests for the protoc plugin and SwiftPM plugin.
# Result
We can now generate `@nonexhaustive` enums and oneofs.
Using e8f93acee8364cf05abc2311f6dbcb1a56a3eeeb
The change to `descriptor.proto` doesn't get captured in the Swift; but it seems
our testing files were stale, so updating them now.
There were two problems to address -
- The shallow checkout github actions do by default didn't have any tags
in the submodule, and we weren't fetching them until doing the update.
So fetch the tags for the protobuf module upfront so the steps can
properly inspect them.
- Since protobuf does language specific tags, most of the time a
language specific tag will be what was collected for the current
checkout, which would still result in all the work being done to then
decide nothing was needed. So change things to collect _all_ tags for
the current comment, and filter them down to the general protobuf tag
instead. This also now errors if anything goes wrong instead of doing
lots of work to then not make a PR.
Fixes#1904
Two parts of `Any` will construct a `Data` unnecessarily, triggering a
memory copy. One is used to serialize a JSON body (stored as an Array of
UInt8) into a Data, by way of an intermediate Array. This intermediate
Array is not necessary: we should go directly to the final Data.
The second is accessing an already serialized value, which already has a
Data in hand, and calls `Data(thatData)`. This initializer looks
innocuous, but `Data` does not actually have a special-case for this, so
this ends up hitting the initializer that takes a `Sequence`, so does a
bulk copy operation instead.
This patch changes both of these to remove extra memory copies when
using Any.