[RF] Avoid using transient `std::unique_ptr`
Harmless change to circumvent errors like these when building RooFit standalone:
Error in <TProtoClass::FindDataMember>: data member with index 0 is not found in class tuple<TreeReadBuffer*,default_delete<TreeReadBuffer> >
Error in <CreateRealData>: Cannot find data member # 0 of class tuple<TreeReadBuffer*,default_delete<TreeReadBuffer> > for parent RooAddPdf!
Error in <TProtoClass::FindDataMember>: data member with index 1 is not found in class tuple<TreeReadBuffer*,default_delete<TreeReadBuffer> >
Error in <CreateRealData>: Cannot find data member # 1 of class tuple<TreeReadBuffer*,default_delete<TreeReadBuffer> > for parent RooAddPdf!
Error in <TProtoClass::FindDataMember>: data member with index 0 is not found in class tuple<TreeReadBuffer*,default_delete<TreeReadBuffer> >
Error in <CreateRealData>: Cannot find data member # 0 of class tuple<TreeReadBuffer*,default_delete<TreeReadBuffer> > for parent RooPolynomial!
Test Results
13 files 13 suites 3d 5h 2m 16s :stopwatch: 3 030 tests 3 030 :white_check_mark: 0 :zzz: 0 :x: 33 869 runs 33 869 :white_check_mark: 0 :zzz: 0 :x:
Results for commit ed22e9b9.
:recycle: This comment has been updated with latest results.
Wait, this should have been fixed by https://github.com/root-project/root/pull/13900. If that's not the case, we need to understand why. FYI @pcanal .
From a practical point of view for RooFit, the fact that the problem is not understood should not block this PR to enter the next patch release, unless the underlying problem is fixed in the meantime.
I'll try to create an easy reproducer and open a GitHub issue!
The original issue (which was "fixed" by also removing the transient unique_ptr because it was blocking the transition to C++17) is at https://github.com/root-project/root/issues/13361
I couldn't create a standalone reproducer back then, also we should probably reintroduce the transient unique_ptr in the RBrowserData class and see what happens.
All of this to say, I agree with you, it's outside of scope for this PR
Harmless change to circumvent errors like these when building RooFit standalone:
Can you remind me how to reproduce this (as you saw it, no need to reduce)?
You need to compile this code with the 3rd commit in the history reverted and run the tests (just like the CI does): https://github.com/guitargeek/roofit/commits/main/
But you need a ROOT build without RooFit for that (roofit=OFF)
Thanks. I am able reproduce that error. I am investigating.
@vepadulano, @pcanal, this PR has already missed the 6.32.02 patch release. Can we merge it so at least this fix is sure to be in the next patch release? The investigation of the problem is independent of this PR I think.
This PR is a 'downgrade' is code simplicity that should not be necessary. However the underlying fix is not ready (and won't until August), so we could temporarily merge this if need be.
Ok, thanks for the comment! Let's see when the next patch release will be scheduled
The 6.32.04 release is planned in about 10 days, according to @dpiparo.
@pcanal, will there be a fix for the underlying issue by then, or should be just merge this PR?
Checking ...
@guitargeek Potential good news. I am currently unable to reproduce the problem with the master nor with the tip of v6-32-00-patches. Can you please verify? Thanks.
@guitargeek Nevermind. I just realized that I can still see the problem when running some of the test :(
https://github.com/root-project/root/pull/16202 should fix this problem. Can you please check?
I see the CI in that PR is still red. Should I wait for the PR to be updated such that it's green before I test? Or does it make sense to test already now?
Thanks a lot already for fixing it :+1:
It makes sense to test it now to know at the very least if my independent tests are sufficient or not.
Perfect! It works!
Superseded by a PR that fixes the underlying problem:
- https://github.com/root-project/root/pull/16202
Re-opening, because this should be merged in case #16202 doesn't get ready for the 6.34 release.