Internal array functions are now implemented in upb/internal/array.c and declared in
upb/internal/array.h, which only has local visibility.
PiperOrigin-RevId: 458260144
some headers were not including port_def.inc
some headers were not declaring extern "C"
some headers were backing out of the above in the wrong order
PiperOrigin-RevId: 457391878
Now that 'size' has been renamed as 'capacity' we are free to rename 'len' as
'size', so upb_Array_Size() is actually returning the 'size' field.
PiperOrigin-RevId: 456865972
The current field/function names for upb_Array are quite confusing.
We will fix them in two steps, this being the first step.
PiperOrigin-RevId: 456687224
It turns out that forward-declaring:
struct foo;
is redundant when combined with:
typedef struct foo foo;
Which is exactly what we were doing in the generated upb code. So, simplify it!
PiperOrigin-RevId: 456590031
Lots of changes but it's all just moving things around.
Backward-compatible stub #include's have been provided for now.
upb_Arena/upb_Status have been split out from upb/upb.?
upb_Array/upb_Map/upb_MessageValue have been split out from upb/collections.?
upb_ExtensionRegistry has been split out from upb/msg.?
upb/decode_internal.h is now upb/internal/decode.h
upb/mini_table_accessors_internal.h is now upb/internal/mini_table_accessors.h
upb/table_internal.h is now upb/internal/table.h
upb/upb_internal.h is now upb/internal/upb.h
PiperOrigin-RevId: 456297617
The cross-compiling Python tests rely on our non-public Docker image, so disable those tests if the PR is coming from an external contributor (otherwise the jobs will fail).
Also modified the Bazel tests to use a read-only cache for external contributors.
PiperOrigin-RevId: 449321283
The previous change did not have the desired effect, because the generated code uses the class named "Message" instead of "CMessage."
There was no real need to use the class "CMessage" instead of "Message." The new name is simpler and will make the previous change work.
PiperOrigin-RevId: 449309343
After some debugging I was able to determine that the Win32 DLL was failing to load libgcc_s_sjlj-1.dll. If we statically link libgcc instead, there should be no runtime dependency on libgcc.
PiperOrigin-RevId: 448338965
Protobuf Team Bot
Joshua Haberman
Copybara-Service
Charlie Burnett
Protobuf Team