Github changed their mac runners to use 3.12 by default, which removed setuptools and is causing breakages in some of our tests.
PiperOrigin-RevId: 578917538
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