[WIP] Improved error handling for template instantiation by bendavid · Pull Request #12449 · root-project/root

bendavid · 2023-03-08T03:41:04Z

Two substantive changes:

Explicitly catch errors in pyroot when the wrapper function fails to compile (this is actually an expanded version of a partial fix which is already upstream in cppyy: wlav/cppyy-backend@8de6ed5)
Make sure template instantiation fails by catching clang errors within LookupHelper and rolling back the transaction where appropriate (still not entirely sure this is exactly the right fix, @Axel-Naumann @jalopezg-git please take a look)
Implement a mechanism for redirecting cling diagnostics to a user provided ostream and use this in cppyy to capture the diagnostic output and append it to the python exceptions or warnings as appropriate

This PR fixes #11854

There are still some remaining problems with the transaction rollback, however template instantiation from cppyy now behaves the same as calling TInterpreter::Declare in this respect. This is likely related to the issues described by @jalopezg-git in #12449 (comment) and can be fixed in a future PR.

Consider the following test case:

test.h:

template <typename T>
class Helper {

public:

  Helper() {}

  std::size_t operator() () const {
    const std::size_t res = 0;
    res = T{0, 0}.size();
    return res;
  }

};

template <typename H>
std::size_t call_helper(const H &helper) {
  return helper();
}

test.py

import ROOT

ret = ROOT.gInterpreter.Declare('#include "test.h"')
print("declare ret", ret)

print("creating helper")
helper = ROOT.Helper[ROOT.std.vector["double"]]()

print("calling helper")

for i in range(2):
   print(f"call attempt {i}")
   try:
      res = ROOT.call_helper(helper)
      print("helper call succeeded:", res)
   except Exception as e:
      print("helper call failed")
      print(e)

The output below is now close to optimal for the first instantiation attempt. On the second instantiation attempt the error message is different/less useful because of the imperfect transaction rollback already noted. (but the same happens instantiating the template through TInterpreter::Declare as said)

declare ret True
creating helper
calling helper
call attempt 0
helper call failed
Template method resolution failed:
  Failed to instantiate "call_helper(Helper<vector<double> >&)"
    In file included from input_line_52:1:
/home/b/bendavid/pyrootdebug6/test.h:10:9: error: cannot assign to variable 'res' with const-qualified type 'const std::size_t' (aka 'const unsigned long')
    res = T{0, 0}.size();
    ~~~ ^
/home/b/bendavid/pyrootdebug6/test.h:18:10: note: in instantiation of member function 'Helper<std::vector<double, std::allocator<double> > >::operator()' requested here
  return helper();
         ^
note: in instantiation of function template specialization 'call_helper<Helper<std::vector<double, std::allocator<double> > > >' requested here
/home/b/bendavid/pyrootdebug6/test.h:9:23: note: variable 'res' declared const here
    const std::size_t res = 0;
    ~~~~~~~~~~~~~~~~~~^~~~~~~

  Failed to instantiate "call_helper(Helper<vector<double> >*)"
    error: called object type 'Helper<std::vector<double, std::allocator<double> > > *' is not a function or function pointer
note: in instantiation of function template specialization 'call_helper<Helper<std::vector<double, std::allocator<double> > > *>' requested here

  Failed to instantiate "call_helper(Helper<vector<double> >)"
    error: type 'const Helper<std::vector<double, std::allocator<double> > >' does not provide a call operator
note: in instantiation of function template specialization 'call_helper<Helper<std::vector<double, std::allocator<double> > > >' requested here

call attempt 1
helper call failed
Template method resolution failed:
  Failed to instantiate "call_helper(Helper<vector<double> >&)"
    error: type 'const Helper<std::vector<double, std::allocator<double> > >' does not provide a call operator
note: in instantiation of function template specialization 'call_helper<Helper<std::vector<double, std::allocator<double> > > >' requested here

  Failed to instantiate "call_helper(Helper<vector<double> >*)"
    error: called object type 'Helper<std::vector<double, std::allocator<double> > > *' is not a function or function pointer
note: in instantiation of function template specialization 'call_helper<Helper<std::vector<double, std::allocator<double> > > *>' requested here

  Failed to instantiate "call_helper(Helper<vector<double> >)"
    error: type 'const Helper<std::vector<double, std::allocator<double> > >' does not provide a call operator
note: in instantiation of function template specialization 'call_helper<Helper<std::vector<double, std::allocator<double> > > >' requested here

(on the console the output also has the nice highlighting and colors one would normally get from clang diagnostic printing, see screenshot below)

Needless to say, taken together this constitutes a major improvement when trying to use complex templated code with pyroot/cppyy

phsft-bot · 2023-03-08T03:41:11Z

Starting build on ROOT-debian10-i386/soversion, ROOT-performance-centos8-multicore/cxx17, ROOT-ubuntu18.04/nortcxxmod, ROOT-ubuntu2004/python3, mac12/noimt, mac11/cxx14, windows10/cxx14
How to customize builds

Axel-Naumann · 2023-03-08T07:44:27Z

The failure to unload broken declarations (@jalopezg-git FYI), does that still happen after this PR, or is this addressed by the PR? I'm not sure I understand how much of the PR description describes this PR vs what's left to be done?

Axel-Naumann

Thanks a lot for your work on this. Can you remind me what typical new failures would look like if instead we were to repeat the lookup without diagnostic suppression, in those cases where cppyy cannot find a suitable function to call?

bendavid · 2023-03-08T12:50:51Z

All of the code example/output in the PR description corresponds to with this PR included.

Repeating the lookup without diagnostic suppression doesn't give the correct error message again
(this corresponds to the "call attempt 1" case in the output from test.py in the PR description)

ie with superfluous debug output snipped out:

declare ret True
creating helper
calling helper
call attempt 0
In file included from input_line_52:1:
/home/b/bendavid/pyrootdebug3/test.h:10:9: error: cannot assign to variable 'res' with const-qualified type 'const std::size_t' (aka 'const unsigned long')
    res = T{0, 0}.size();
    ~~~ ^
/home/b/bendavid/pyrootdebug3/test.h:18:10: note: in instantiation of member function 'Helper<std::vector<double, std::allocator<double> > >::operator()' requested here
  return helper();
         ^
note: in instantiation of function template specialization 'call_helper<Helper<std::vector<double, std::allocator<double> > > >' requested here
/home/b/bendavid/pyrootdebug3/test.h:9:23: note: variable 'res' declared const here
    const std::size_t res = 0;
    ~~~~~~~~~~~~~~~~~~^~~~~~~
/home/b/bendavid/pyrootdebug3/test.h:18:10: error: called object type 'Helper<std::vector<double, std::allocator<double> > > *' is not a function or function pointer
  return helper();
         ^~~~~~
note: in instantiation of function template specialization 'call_helper<Helper<std::vector<double, std::allocator<double> > > *>' requested here
helper call failed
Template method resolution failed:
  Failed to instantiate "call_helper(Helper<vector<double> >&)"
  Failed to instantiate "call_helper(Helper<vector<double> >*)"
  Failed to instantiate "call_helper(Helper<vector<double> >)"
call attempt 1
/home/b/bendavid/pyrootdebug3/test.h:18:10: error: called object type 'Helper<std::vector<double, std::allocator<double> > > *' is not a function or function pointer
  return helper();
         ^~~~~~
note: in instantiation of function template specialization 'call_helper<Helper<std::vector<double, std::allocator<double> > > *>' requested here
helper call failed
Template method resolution failed:
  Failed to instantiate "call_helper(Helper<vector<double> >&)"
  Failed to instantiate "call_helper(Helper<vector<double> >*)"
  Failed to instantiate "call_helper(Helper<vector<double> >)"

So the relevant error message error: cannot assign to variable 'res' with const-qualified type 'const std::size_t' (aka 'const unsigned long') only appears in the first attempt (and is only printed because I've set gDebug=6 here)

bendavid · 2023-03-09T12:10:04Z

Failure for ubuntu20 build looks possibly unrelated to this PR.

bendavid · 2023-03-11T16:25:56Z

So in fact there is already a problem with rolling back the transaction even when just using TInterpreter::Declare:

test.h

template <typename T>
class Helper {

public:

  Helper() {}

  std::size_t operator() () const {
    const std::size_t res = 0;
    res = T{0, 0}.size();
    return res;
  }

};

template <typename H>
std::size_t call_helper(const H &helper) {
  return helper();
}

testdeclare.py

import ROOT

ret = ROOT.gInterpreter.Declare('#include "test.h"')
print("header include ret", ret)

print("creating helper")
helper = ROOT.Helper[ROOT.std.vector["double"]]()

bad_template = "template std::size_t call_helper<Helper<std::vector<double>>>(const Helper<std::vector<double>>&);"

for i in range(2):
    print(f"declare attempt {i}")
    ret = ROOT.gInterpreter.Declare(bad_template)
    print("ret", ret)

output:

header include ret True
creating helper
declare attempt 0
In file included from input_line_52:1:
/home/b/bendavid/pyrootdebug3/test.h:10:9: error: cannot assign to variable 'res' with const-qualified type 'const std::size_t' (aka 'const unsigned long')
    res = T{0, 0}.size();
    ~~~ ^
/home/b/bendavid/pyrootdebug3/test.h:18:10: note: in instantiation of member function 'Helper<std::vector<double, std::allocator<double> > >::operator()' requested here
  return helper();
         ^
/home/b/bendavid/pyrootdebug3/test.h:9:23: note: variable 'res' declared const here
    const std::size_t res = 0;
    ~~~~~~~~~~~~~~~~~~^~~~~~~
ret False
declare attempt 1
/home/b/bendavid/pyrootdebug3/test.h:18:10: error: type 'const Helper<std::vector<double, std::allocator<double> > >' does not provide a call operator
  return helper();
         ^~~~~~
input_line_55:1:22: note: in instantiation of function template specialization 'call_helper<Helper<std::vector<double, std::allocator<double> > > >' requested here
template std::size_t call_helper<Helper<std::vector<double>>>(const Helper<std::vector<double>>&);
                     ^
ret False

So again the error message is different/more obscure on the second attempt at explicit template instantiation.

jalopezg-git · 2023-03-14T10:50:38Z

The failure to unload broken declarations (@jalopezg-git FYI), does that still happen after this PR, or is this addressed by the PR? I'm not sure I understand how much of the PR description describes this PR vs what's left to be done?

I don't know how this PR relates to the unloading issues in cling. What I saw in the past is that DeclUnloader is buggy; specifically, it always removes declarations from the AST when that's not always appropriate. One case in which this fails is for members of a templated class (which clang initially marks as "pending instantiation").
If those are instantiated implicitly as part of a transaction that fails, DeclUnloader removes the member declaration. This prevents the decl from being re-emitted when needed. Instead, it should be left in the previous state and marked as "pending instantiation" again.
I have some code that should fix this (which coincides with most if not all the reported unloading issues). I will clean it and open a PR as soon as I finish the current on-going RNTuple work. 🙂

bendavid · 2023-03-19T22:57:50Z

After modifying the logic to catch the error and fail the transaction rather than unloading the decl directly, repeated attempts at template instantiation from pyroot now behaves similarly to with TInterpreter::Declare. The remaining problems with incomplete rollback are almost certainly related to the issue which @jalopezg-git referred to, and can be fixed by his forthcoming PR.

Still TODO for this PR:
Capture and print the relevant errors and warnings during template instantiation.

github-actions · 2023-03-19T23:56:10Z

Test Results

22 files 22 suites 3d 19h 19m 38s ⏱️
3 781 tests 3 776 ✅ 0 💤 5 ❌
81 254 runs 81 200 ✅ 0 💤 54 ❌

For more details on these failures, see this check.

Results for commit dee2fb7.

♻️ This comment has been updated with latest results.

bendavid · 2023-03-21T19:45:28Z

The failure in tutorial-roofit-rf408_RDataFrameToRooFit-py is actually a real error which wasn't being caught before (a rather subtle SFINAE problem)

bendavid · 2023-03-22T15:28:59Z

PR and description updated addressing also the diagnostic capture and printing.

I'm still not totally sure about how the catching of errors and rollback of the transaction is handled in LookupHelper as said in the description.

bendavid · 2023-03-22T15:30:03Z

Any ideas on the remaining windows failure would also be welcome (it doesn't happen on linux and I don't have a windows setup to test with at the moment)

jalopezg-git

Thanks for the contribution (and sorry for the delay in the review), @bendavid! 🙂 I have attached some comments to further improve the PR.

Regarding the unloading errors that I mentioned in one of my previous comments, I'll open a pull request soon.

phsft-bot · 2023-05-01T15:52:02Z

Build failed on windows10/cxx14.
Running on null:C:\build\workspace\root-pullrequests-build
See console output.

Failing tests:

projectroot.roottest.cling.dict.roottest_cling_dict_assertTmpltDefArgCtor

jalopezg-git · 2023-07-20T09:55:13Z

I think this PR stalled for a while; perhaps we can give it a push and finally merge in the coming weeks?

bendavid · 2023-07-20T14:44:52Z

Yes ok I can come back to this next week.

jalopezg-git · 2023-08-31T12:22:18Z

There are still some remaining problems with the transaction rollback, however template instantiation from cppyy now behaves the same as calling TInterpreter::Declare in this respect. This is likely related to the issues described by @jalopezg-git in #12449 (comment) and can be fixed in a future PR.

FYI, #13565 should fix the issues with unloading that I mentioned before in this PR! I still need to look at two test failures, but it's mostly there 🙂!

jalopezg-git · 2023-12-05T14:02:23Z

There are still some remaining problems with the transaction rollback, however template instantiation from cppyy now behaves the same as calling TInterpreter::Declare in this respect. This is likely related to the issues described by @jalopezg-git in #12449 (comment) and can be fixed in a future PR.

FYI, #13565 should fix the issues with unloading that I mentioned before in this PR! I still need to look at two test failures, but it's mostly there 🙂!

@bendavid #13565 was recently merged into master. Provided that you have the time, you could rebase this PR and see how it works now.

bendavid · 2024-10-04T13:09:13Z

(Updated to fix code formatting)

ferdymercury · 2025-08-06T07:14:51Z

@wlav What do you think of the cppyy related changes?

wlav · 2025-08-06T21:13:24Z

From a quick look: indentation is all over the place (4 -> 3; tabs; missing indentation) and some of the new error messages are very verbose, which will look bad on a simple Python command prompt. The addition of a do-nothing ostringstream in the C api could do with a comment.

Of the new functionality, the diagnostics are probably fine, but some of the newly added error setting (e.g in Instantiate) may break tests (would have to see).

The one thing that can't happen is CallConstructor throwing exceptions. It makes it impossible to use from the C api.

guitargeek · 2025-08-07T08:38:13Z

Thank you for commenting @wlav!

@bendavid, do you still want to work on this PR yourself? Or should I take it over and bring it to a mergeable state?

bendavid · 2025-08-13T14:39:58Z

@guitargeek I'm on vacation until Aug. 27. I can look at this again when I'm back, but you're also welcome to take this over.

In case it helps I had rebased this on top of 6.34.04 a little while ago, so some of the conflicts may already be solved in https://github.com/bendavid/root/tree/v6-34-04-patches

…g the decl

…ed ostream

…directed

…ler errors and warnings during template instantiation

…available on all build platforms

…ed with jitted version of Book

vepadulano · 2025-11-29T13:41:05Z

@bendavid I've taken the liberty of rebasing the branch on latest master, make some little adaptations to address review comments, and add a test.

vepadulano · 2025-11-29T13:44:53Z

+    R__WRITE_LOCKGUARD(ROOT::gCoreMutex);
+
+    const std::string diagnosticsold = diagnostics.str();
+    TInterpreter::RedirectDiagnostics redirectRAII(gInterpreter, diagnostics, /*enableColors*/ true, /*indent*/ 4);


I wonder how this interacts with the future rebase of clingwrapper on top of CppInterop @aaronj0 @Vipul-Cariappa . Do we have similar infrastructure for retrieving interpreter diagnostics without leaking implementation details here?

We currently do not have a way of doing this. But it should be relatively easy to implement. The question of "without leaking implementation details", not sure about that. If the question is: Can we propagate why a template instantiation fails? Yes, we propagate the reason.

Maybe a clearer rephrasing of my question would be "can we obtain the same interpreter diagnostics in clingwrapper.cxx, without using any ROOT facility (i.e. R__WRITE_LOCKGUARD, ROOT::gCoreMutex, TInterpreter in this case), so that this diagnostic can become something generic and still give us the chance one day of outsourcing clingwrapper.cxx?"

"can we obtain the same interpreter diagnostics in clingwrapper.cxx, without using any ROOT facility (i.e. R__WRITE_LOCKGUARD, ROOT::gCoreMutex, TInterpreter in this case)

The way I see it, we will still need the gCore mutex for the clingwrapper API to continue supporting ROOT threading model. Which is not a problem since we still link against Core in the design that migrates to InterOp.

so that this diagnostic can become something generic and still give us the chance one day of outsourcing clingwrapper.cxx

As Vipul mentioned, obtaining the diagnostic itself is not yet supported, but it can indeed be done generically, i.e., based on Clang's diagnostics engine (like this PR does). Based on that, I would comment that the right place for the very nice TClingDiagnosticsRAII implemented by this PR is probably CppInterOp, which solves the concern on whether this can be generalized and outsourced. In my view, clingwrapper is the one part that will/should contain ROOT-specific extensions on top of CppInterOp. @vgvassilev can comment on the changes in Cling's LookupHelper, but on first glance, that looks good to me.

One way to proceed is to keep the current approach and, as part of the migration, upstream the diagnostics from TCling to CppInterOp, and revert the changes in TInterpreter, since we can then interact with the Cpp::Interpreter directly. If the need for this PR is not immediate, the easier option is to revisit it on top of the migration PR. Ideally, we shouldn't grow further the interactions between Core and the interpreter via metacling for cppyy use cases. Apart from that, this PR heads in the right direction and proposes some quite nice additions.

vepadulano · 2026-01-07T11:49:38Z

Just to keep track of my advancements, here is my plan regarding this PR to address the problem properly while ensuring a sustainable transition:

Separate the changes that go into LookupHelper.cpp into a separate PR
Then prepare a PR for CppInterop that contains most of the changes in core/metacling to allow propagating the diagnostics
Test the new facility in CppInterop in clingwrapper.cxx, with the aim of avoiding any ROOT usage in clingwrapper
Finally, adapt CPyCppyy to use the new facility

This will require some more time 🚧

This is the first part of root-project#12449 Co-authored-by: Josh Bendavid <Josh.Bendavid@cern.ch>

bendavid requested review from Axel-Naumann and vepadulano as code owners March 8, 2023 03:41

bendavid force-pushed the template_error_handling branch from b8e1515 to 1e89113 Compare March 8, 2023 03:45

Axel-Naumann reviewed Mar 8, 2023

View reviewed changes

Comment thread interpreter/cling/lib/Interpreter/LookupHelper.cpp Outdated

couet assigned vepadulano Mar 10, 2023

bendavid force-pushed the template_error_handling branch from ac63baf to 59c2de3 Compare March 21, 2023 14:04

bendavid requested a review from pcanal as a code owner March 21, 2023 14:04

bendavid force-pushed the template_error_handling branch 2 times, most recently from 2aa7e7a to 4e29a95 Compare March 21, 2023 18:01

bendavid requested review from guitargeek, hageboeck and lmoneta as code owners March 21, 2023 19:47

bendavid commented Mar 25, 2023

View reviewed changes

Comment thread interpreter/cling/lib/Interpreter/LookupHelper.cpp

jalopezg-git suggested changes May 1, 2023

View reviewed changes

bendavid and others added 15 commits November 29, 2025 11:54

explicitly throw errors when WrapperCall fails

d77d990

improve error message when function call fails

b8ea44f

catch errors during template instantiation

93bb21a

handle failures through the transaction rather than directly unloadin…

2e1fbf3

…g the decl

fix handling of failures via the transaction

5bf70b5

implement redirection of interpreter diagonstic output to user-provid…

81dd620

…ed ostream

don't suppress lookup diagnostics when interpreter output is being re…

b206bcf

…directed

use redirection of interpreter diagnostics to capture and print compi…

bb7f3ef

…ler errors and warnings during template instantiation

use PyErr_WarnEx instead of PyErr_WarnFormat since the latter is not …

a230a27

…available on all build platforms

add improved error handling to tpp_overload as well

7756ea8

improve error handling in tpp_overload

629664b

suppress warnings and errors when lookup succeeds on a subsequent try

d9e2515

Adapt patches to master

24f783b

explicitly handle 0 column case to avoid instantiation errors when us…

cda3147

…ed with jitted version of Book

[python] Add regression test for root-project#11854

dee2fb7

vepadulano force-pushed the template_error_handling branch from 8b22039 to d9e2515 Compare November 29, 2025 13:38

vepadulano requested a review from bellenot as a code owner November 29, 2025 13:40

vepadulano reviewed Nov 29, 2025

View reviewed changes

vepadulano closed this Nov 30, 2025

vepadulano reopened this Nov 30, 2025

vepadulano added a commit to vepadulano/root that referenced this pull request Jan 19, 2026

[cling] Do not suppress all diagnostics during function lookup

c007387

This is the first part of root-project#12449 Co-authored-by: Josh Bendavid <Josh.Bendavid@cern.ch>

vepadulano added a commit to vepadulano/root that referenced this pull request Jan 19, 2026

[cling] Do not suppress all diagnostics during function lookup

ab704f9

This is the first part of root-project#12449 Co-authored-by: Josh Bendavid <Josh.Bendavid@cern.ch>

vepadulano mentioned this pull request Jan 19, 2026

[cling] Do not suppress all diagnostics during function lookup #20946

Draft

Uh oh!

Conversation

bendavid commented Mar 8, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

phsft-bot commented Mar 8, 2023

Uh oh!

Axel-Naumann commented Mar 8, 2023

Uh oh!

Axel-Naumann left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

bendavid commented Mar 8, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

bendavid commented Mar 9, 2023

Uh oh!

bendavid commented Mar 11, 2023

Uh oh!

jalopezg-git commented Mar 14, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

bendavid commented Mar 19, 2023

Uh oh!

github-actions Bot commented Mar 19, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Test Results

Uh oh!

bendavid commented Mar 21, 2023

Uh oh!

bendavid commented Mar 22, 2023

Uh oh!

bendavid commented Mar 22, 2023

Uh oh!

Uh oh!

jalopezg-git left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

phsft-bot commented May 1, 2023

Failing tests:

Uh oh!

jalopezg-git commented Jul 20, 2023

Uh oh!

bendavid commented Jul 20, 2023

Uh oh!

jalopezg-git commented Aug 31, 2023

Uh oh!

jalopezg-git commented Dec 5, 2023

Uh oh!

bendavid commented Oct 4, 2024

Uh oh!

ferdymercury commented Aug 6, 2025

Uh oh!

wlav commented Aug 6, 2025

Uh oh!

guitargeek commented Aug 7, 2025

Uh oh!

bendavid commented Aug 13, 2025

Uh oh!

vepadulano commented Nov 29, 2025

Uh oh!

vepadulano Nov 29, 2025

Choose a reason for hiding this comment

Uh oh!

Vipul-Cariappa Dec 1, 2025

Choose a reason for hiding this comment

Uh oh!

vepadulano Dec 1, 2025

Choose a reason for hiding this comment

bendavid commented Mar 8, 2023 •

edited

Loading

bendavid commented Mar 8, 2023 •

edited

Loading

jalopezg-git commented Mar 14, 2023 •

edited

Loading

github-actions Bot commented Mar 19, 2023 •

edited

Loading

aaronj0 Dec 1, 2025 •

edited

Loading