Suppress -Wmaybe-uninitialized for onnxruntime_pybind11_state under pybind11 3.0

[Rishi-Dave]

Summary

• Probes -Wmaybe-uninitialized via check_cxx_compiler_flag and applies -Wno-maybe-uninitialized only to the onnxruntime_pybind11_state target when the compiler accepts it.
• Fixes the GCC build break introduced when ORT is compiled against pybind11 3.0, currently blocking Fedora's pybind11 3.0 package update.

Motivation

pybind11 3.0 rewrote def_readwrite to use a property_cpp_function_classic template that generates a lambda capturing a member pointer by value. GCC's -Wmaybe-uninitialized flow analysis flags that lambda inside pybind11's own headers, so any consumer compiling ORT's Python bindings against system pybind11 3.0 fails the build. This is a header-side false positive — there is no real uninitialized read in ORT code or in pybind11.

Fixes #25681

Changes

• cmake/CMakeLists.txt: add check_cxx_compiler_flag(-Wno-maybe-uninitialized HAS_NO_MAYBE_UNINITIALIZED) next to the existing HAS_CAST_FUNCTION_TYPE probe.
• cmake/onnxruntime_python.cmake: when HAS_NO_MAYBE_UNINITIALIZED is set, append -Wno-maybe-uninitialized to the onnxruntime_pybind11_state target's private compile options. Mirrors the established HAS_CAST_FUNCTION_TYPE pattern in the same file.

The suppression is target-scoped (only the Python binding shared library), compiler-scoped (only when the flag is accepted — effectively GCC), and warning-scoped (only the flow-sensitive -Wmaybe-uninitialized, not the strict -Wuninitialized).

Test Plan

• lintrunner -a clean on the diff.
• CI: confirm Linux GCC builds remain green.
• Downstream verification: Fedora packagers can rebuild ORT against system pybind11 3.0 without -Wmaybe-uninitialized errors (per issue reporter).

[tianleiwu]

Review Summary

Clean, well-motivated fix for the pybind11 3.0 GCC build break. The target-scoped suppression with clear comments and issue reference follows established patterns nicely.

One suggestion to simplify: cmake/CMakeLists.txt already probes for -Wmaybe-uninitialized (positive form) at line 651 and sets HAS_MAYBE_UNINITIALIZED. Since GCC always pairs -W<x> and -Wno-<x> flags, the new HAS_NO_MAYBE_UNINITIALIZED probe is redundant. Using the existing variable would reduce this to a single-file change and match the HAS_CAST_FUNCTION_TYPE pattern (probe positive form, apply negative form).

[tianleiwu]

Suggestion: This probe is redundant — line 651 of this file already does:

check_cxx_compiler_flag(-Wmaybe-uninitialized HAS_MAYBE_UNINITIALIZED)

GCC always pairs -W<x> and -Wno-<x>, so if HAS_MAYBE_UNINITIALIZED is true, -Wno-maybe-uninitialized is guaranteed to be accepted. You can drop this new line entirely and use if(HAS_MAYBE_UNINITIALIZED) in onnxruntime_python.cmake instead.

This also fixes the ordering issue — the new line is currently placed among the 'c' flags, but alphabetically -Wno-maybe-uninitialized (or its 'm' base) belongs later in the list.

Matches the existing pattern where HAS_CAST_FUNCTION_TYPE probes the positive form and the target applies the negative -Wno-cast-function-type.

[Rishi-Dave]

Thanks for the catch — pushed acae123 which drops the redundant -Wno-maybe-uninitialized probe and reuses the existing HAS_MAYBE_UNINITIALIZED from CMakeLists.txt:651 to gate the suppression in onnxruntime_python.cmake, mirroring the HAS_CAST_FUNCTION_TYPE pattern. Net diff is now a single condition in onnxruntime_python.cmake — no new probe added.