[bendavid]

This Pull request:

Reports the compiler diagnostics from instantiating templates called from Python with the cppjit bindings, and rejects ill-formed instantiations instead of silently running them. This replaces #12449 for the CppInterOp/cppjit-based bindings, following the split proposed at the end of that PR's discussion (CppInterOp facility first, then its use in the bindings).

Note on the vendored CppInterOp: this PR edits the copy in interpreter/CppInterOp directly. It is therefore expected to fail the cppinterop-diff check and not meant to be merged in this form. It's opened to make the complete change visible and testable for the discussion. The CppInterOp part is proposed upstream as compiler-research/CppInterOp#1179, rebuilt on the current main there. Once that is settled, the vendored copy would come in through the usual ROOT-cppjit update, and this PR would reduce to the cppjit and test commits.

For the same reason, the cppjit-diff check is expected to fail: bindings/pyroot/cppjit is likewise a vendored copy of compiler-research/cppjit, and the cppjit changes here would go upstream there as well. The clang-format check's only suggestion is to reformat the new entry in the vendored CppInterOp.td (a TableGen file) in ROOT's C++ style. That isn't applied, to keep the entry consistent with the rest of the file and with upstream.

Changes or fixes:

• [cppinterop] (vendored, upstream as Reject ill-formed template bodies in BestOverloadFunctionMatch and capture their diagnostics compiler-research/CppInterOp#1179):
  • When BestOverloadFunctionMatch instantiates the body of the best match, the match is now rejected if any error occurred, not only if the specialization was marked invalid. Errors such as a failing static_assert or an error in a nested instantiation leave it valid. Previously those cases either ran code that shouldn't have compiled, or failed at link time without the compiler error being shown.
  • The rejected specialization is marked invalid, so later lookups reject it too.
  • The diagnostics are rendered as clang prints them, instead of being suppressed, and returned by the new GetLastOverloadMatchDiagnostics().
• [cppjit]:
  • The compiler errors are included in the TypeError for a failed instantiation, indented under the corresponding "Failed to instantiate" line.
  • Warnings from a successful instantiation are reported as a Python UserWarning.
• [python] tests:
  • New template_instantiation_diagnostics.py, including the reproducer from Bad error handling with pyroot template instantiations #11854 and a failing static_assert.
  • test19_templated_operator_add gets the friend declaration it needs: its operator+ accessed private members of other specializations, which is ill-formed (gcc and clang reject it) and is now also rejected from Python.

Example (from #11854): instead of a link-time failure with no explanation, you now get:

TypeError: Template method resolution failed:
  Failed to instantiate "call_gh11854_helper(::GH11854Helper<std::vector<double,std::allocator<double> > >&)"
    input_line_26:2:110: error: cannot assign to variable 'res' with const-qualified type 'const std::size_t' (aka 'const unsigned long')
    ...
    note: in instantiation of member function 'GH11854Helper<std::vector<double, std::allocator<double> > >::operator()' requested here

Checklist:

• tested changes locally: built master with these commits (gminimal, pyroot, testing, C++20, Arch Linux with GCC). All 65 cppjit|pyroot ctests pass, including the new pyroot-template-instantiation-diagnostics and cppjit-test-templates. The CppInterOp unit tests for the upstream version are described in Reject ill-formed template bodies in BestOverloadFunctionMatch and capture their diagnostics compiler-research/CppInterOp#1179.
• updated the docs (if necessary)

This PR fixes #11854

🤖 Generated with Claude Code

[vepadulano]

Hi @bendavid ,

Thanks for this contribution! FWIW, note that I had started to implement your original PR, splitting it by the 4 categories I had highlighted at #12449 (comment)

The first part of this is #20946, which immediately failed on many regards and was apparently backwards incompatible (at least on the surface) from the point of view of cling, not even touching the Python bindings. In particular, see this issue I had opened as a followup to the failures in my PR #20952. Also, as I noted in my PR, I was not able to create a clear, C++-only reproducer to pinpoint how the changes actually fix something without breaking anything else. I believe all of this should be addressed before considering the rest of this PR. Unless this PR is adopting a completely different approach w.r.t. before, such that cling is not touched and all my premise loses relevance.

[vepadulano]

I just took a look at the code changes and indeed they do not touch cling anymore, which is both relieving and surprising. In any case, I would like to see if #20952 is now fixed to close that other effort without running the risk of leaving behind us untracked issues.