[copybara-service]

Require operator== to bind without errors before implementing PartialOrd

When a C++ record defines operator== with an unsupported signature (such as returning int instead of bool) alongside a relational or three-way comparison operator (<=>, <, >, <=, >=) that returns bool, generate_function still returns Ok(Some(GeneratedFunction)) for operator== with status: Err(...) so it can emit an uncallable PartialEq impl with an unsatisfied where for<'error> &'error (): BindingFailedFor_... bound.

Previously, BindingsGenerator::get_binding only checked generate_function(...).ok().flatten().is_some(), treating any Some(GeneratedFunction) as a valid binding regardless of status. As a result, api_func_shape_for_operator_partial_ord saw operator== as implementing PartialEq and emitted an unconditional impl PartialOrd calling self == other, which failed to compile because the PartialEq supertrait bound was unsatisfied.

Include generated_function.status.is_ok() in the tuple returned by get_binding:

• api_func_shape_for_operator_partial_ord requires status.is_ok() (true) when checking whether operator== implements PartialEq (and when checking whether a preferred comparison operator already implements PartialOrd).
• api_func_shape_for_operator_ne continues to skip operator!= whenever operator== generates a PartialEq impl (even with status.is_err()), avoiding duplicate PartialEq::eq overload collisions in overload_sets.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.