setup-gcloud doesn't honor the environment variables set by setup-python, so we need to manually set CLOUDSDK_PYTHON before running it.
PiperOrigin-RevId: 578674246
Previously we were allocating memory on the message's arena every time we performed a `map[key]` or `map.get(key)` operation. This is unnecessary, as the key's data is only needed ephemerally, for the duration of the lookup, and we can therefore alias the Python object's string data instead of copying it.
This required fixing a bug in the convert.c operation. Previously in the `arena==NULL` case, if the user passes a bytes object instead of a unicode string, the code would return a pointer to a temporary Python object that had already been freed, leading to use-after-free. I fixed this by referencing the bytes object's data directly, and using utf8_range to verify the UTF-8.
Fixes: https://github.com/protocolbuffers/protobuf/issues/14571
PiperOrigin-RevId: 578563555
Previously we were allocating memory on the message's arena every time we performed a `map[key]` or `map.get(key)` operation. This is unnecessary, as the key's data is only needed ephemerally, for the duration of the lookup, and we can therefore alias the Python object's string data instead of copying it.
This required fixing a bug in the convert.c operation. Previously in the `arena==NULL` case, if the user passes a bytes object instead of a unicode string, the code would return a pointer to a temporary Python object that had already been freed, leading to use-after-free. I fixed this by referencing the bytes object's data directly, and using utf8_range to verify the UTF-8.
Fixes: https://github.com/protocolbuffers/protobuf/issues/14571
PiperOrigin-RevId: 578563555
gRPC auto-generates CMake and other build configs from the Bazel build graph,
but the logic for doing this does not know how to handle filegroups. This
change works around that problem by making the `:port` target refer directly to
the `.inc` files instead of going through a filegroup. This solution is not
ideal but I think it's probably the best way to unblock progress for now.
PiperOrigin-RevId: 578333954
gRPC auto-generates CMake and other build configs from the Bazel build graph,
but the logic for doing this does not know how to handle filegroups. This
change works around that problem by making the `:port` target refer directly to
the `.inc` files instead of going through a filegroup. This solution is not
ideal but I think it's probably the best way to unblock progress for now.
PiperOrigin-RevId: 578333954
Because pure python builds all descriptors at runtime via reflection, it's unable to parse options during the build of descriptor.proto (i.e. before we've built the options schemas). We always lazily parse these options to avoid this, but that still means options can't be *used* during this build. Since the current build process makes heavy use of features (which previously just relied on syntax), this poses a problem for editions.
To get around this, we just embed the resolved features directly into the gencode for this one file. This will allow us to skip feature resolution for these descriptors and still consider features in their build.
PiperOrigin-RevId: 577495949
These tests aren't super useful for python because of how little codegen we actually do, but the pyi ones specifically will guard against major editions regressions.
PiperOrigin-RevId: 577495652
Writing zeros is faster as they are often available in the cache as well as it can be done with less instructions on common platforms.
```
BM_RepeatedPtrField_Ctor 125ns ± 3% 118ns ± 3% -5.34% (p=0.000 n=217+219)
```
PiperOrigin-RevId: 576126835
Jie Luo
Deanna Garcia
Protobuf Team Bot
Eric Salo
Mike Kruskal
Joshua Haberman
Cong Liu
Protobuf Team Bot
Joshua Haberman
Adam Cozzette
Alex Potsides
zhangskz
Jason Lunn
Jakob Buchgraber
Chris Kennelly
Kevin King
Martijn Vels
st-cheewah