Before, the upb_ExtensionRegistry_AddArray API would just return a boolean
indicating whether the operation succeeded or failed. This is not descriptive
enough in some cases and made the error output confusing.
Specifically, when trying to register an extension with a duplicate extension
number, AddArray first performs a map lookup before inserting the extension
entry into the registry. The code handled lookup failure (due to duplicates)
the same way as insertion failure (due to OOM), and printed an error message
that showed OOM when there is a duplicate array entry.
This was acknolwedged in a TODO in the AddArray code comment -- which is now
fixed. :)
PiperOrigin-RevId: 700764584
We previously hit this for NAN, but it appears the latest version of MSVC used in windows github runners has the same issue for INFINITY. The same strategy can be applied here.
This will be backported to fix broken release branches.
PiperOrigin-RevId: 700042372
After using UPB I noticed that field accessors were not getting inlined properly using Clang. The source appears to be the UPB_FORCEINLINE macro falling back to just being `static` when underneath clang despite clang having full support of the required attributes.
Closes#17433
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/17433 from Vadmeme:main 57204e78cd
PiperOrigin-RevId: 699195477
Before we were trying to work around the fact that we don't know the default depth limit. The logic is simpler and more robust if we take the default into account.
PiperOrigin-RevId: 698856552
Prior to this CL, the fuzz tests only checked that the code does not crash, but it was not checking any correctness properties. This CL adds correctness checking, verifying that we can round trip through the wire format without losing or corrupting data.
This highlighted a minor bug in the encoder where the depth limit check was off by one (too strict). This CL makes the encoder more accepting when checking the depth limit.
PiperOrigin-RevId: 698527429
Adds test coverage for invalid empty strings (e.g. ""), non-numeric strings (e.g. "abc"), and partially-numeric strings (e.g. "12abc"), as well as valid exponential numeric strings ("1e5)
We will target enforcing non-conformant cases that should have failed to parse but didn't in upb in v30.x (our ~annual breaking release in some languages). Conformance failures to accept input we previously failed on can be landed at any time.
PiperOrigin-RevId: 694269337
This didn't require any change to the algorithm, except to mark one extra (immutable) member as atomic. It did require changing the tests though.
PiperOrigin-RevId: 690751567
This ports upb's WORKSPACE scraping logic to protobuf, and allows us to dynamically fetch our dependencies at the exact same pinned version as in Bazel via protobuf_FETCH_DEPENDENCIES=ON. This is mostly for development purposes, and is preferable to git submodules. In a later cl we will flip the default behavior to "package"
#test-continuous
PiperOrigin-RevId: 686265348
In C23, `false` is now of type `bool`, not `int`. This turned a couple places where `false` was returned instead of `NULL` into errors.
The workaround in upb for Windows's broken NAN macro causes an error in Clang under C23, `cannot compile this static initializer yet`, I believe because `0.0 / 0.0` is not valid in constant-evaluation. This seems like it's probably a legitimate result of C23 standardizing constexpr, although it _could_ be a clang bug. In any case, refine the workaround a bit, to avoid this problem.
I've also reverted the kUpb_FltInfinity/kUpb_Infinity back to their former definitions, as INFINITY wasn't broken by the windows header, only NAN.
PiperOrigin-RevId: 683152452
Protobuf Team Bot
Protobuf Team Bot
Tony Liao
Taylor Cramer
Mike Kruskal
Vadmeme
Joshua Haberman
Jie Luo
Hong Shin
Sandy Zhang