-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GetMethodWithPrototype return the incorrect function ? #7955
Comments
Caused by d2afe2d |
…ext: Instead of picking a "random" (the first) specialization when building the name of a non-dependent member type of a template, pick the one that corresponds to the "current" specialization. As CreateNestedNameSpecifierForScopeOf cannot know what's "current", this context needs to be passed down / propagated. Add a couple of asserts that the context is provided when needed, and is a template specialization that matches the type at hand. This fixes root-project#7955.
This is critical because we might load who knows what into the frameworks. But because the fix is rather intrusive, and the OP has a simple workaround, I'll not backport the fixes to our existing release branches. |
…ext: Instead of picking a "random" (the first) specialization when building the name of a non-dependent member type of a template, pick the one that corresponds to the "current" specialization. As CreateNestedNameSpecifierForScopeOf cannot know what's "current", this context needs to be passed down / propagated. Add a couple of asserts that the context is provided when needed, and is a template specialization that matches the type at hand. This fixes root-project#7955.
…ext: Instead of picking a "random" (the first) specialization when building the name of a non-dependent member type of a template, pick the one that corresponds to the "current" specialization. As CreateNestedNameSpecifierForScopeOf cannot know what's "current", this context needs to be passed down / propagated. Add a couple of asserts that the context is provided when needed, and is a template specialization that matches the type at hand. This fixes root-project#7955.
I rebased @Axel-Naumann 's PR #8124 into #16232, the tests are passing and the reproducer seems to be fixed by it. @dpiparo how do we want to proceed with this? |
Thanks @silverweed @dpiparo to come back to this. However, thanks very much. |
…ext: Instead of picking a "random" (the first) specialization when building the name of a non-dependent member type of a template, pick the one that corresponds to the "current" specialization. As CreateNestedNameSpecifierForScopeOf cannot know what's "current", this context needs to be passed down / propagated. Add a couple of asserts that the context is provided when needed, and is a template specialization that matches the type at hand. This fixes root-project#7955.
…ext: Instead of picking a "random" (the first) specialization when building the name of a non-dependent member type of a template, pick the one that corresponds to the "current" specialization. As CreateNestedNameSpecifierForScopeOf cannot know what's "current", this context needs to be passed down / propagated. Add a couple of asserts that the context is provided when needed, and is a template specialization that matches the type at hand. This fixes root-project#7955.
…ext: Instead of picking a "random" (the first) specialization when building the name of a non-dependent member type of a template, pick the one that corresponds to the "current" specialization. As CreateNestedNameSpecifierForScopeOf cannot know what's "current", this context needs to be passed down / propagated. Add a couple of asserts that the context is provided when needed, and is a template specialization that matches the type at hand. This fixes root-project#7955.
@srimanob we are having issues in reproducing the issue: could the CMS team give us a hand? @silverweed |
Hi @silverweed @dpiparo I just use the script mentioned in the beginning of this issue and try to run on bare root on lxplus. If I run barely, I get
But if I source ROOT first (to the same version), and try the script, I got the wrong type.
Additional test on ROOT through CMSSW which is still in 6.30, I get the wrong type (same as original report). |
@srimanob thanks a lot for the details! |
Hi @silverweed I ping our framework and CUDA experts to have a look. By the way, do you understand why if I use ROOT that comes on lxplus, no source of ROOT environment, it shows differently than I source ROOT environment first? |
@srimanob I don't really know why that happens, but it's surely an interesting piece of the puzzle. Unfortunately I'm not familiar enough with cling to draw any conclusion, but perhaps @dpiparo, @vgvassilev or other experts of the subject may have a better understanding of it. |
…ext: Instead of picking a "random" (the first) specialization when building the name of a non-dependent member type of a template, pick the one that corresponds to the "current" specialization. As CreateNestedNameSpecifierForScopeOf cannot know what's "current", this context needs to be passed down / propagated. Add a couple of asserts that the context is provided when needed, and is a template specialization that matches the type at hand. This fixes root-project#7955.
As seen by CMS on cms-sw/cmssw#33466
The following piece of lookup:
print
where one would expect
This has catastrophic consequence when combined with autoloading of library.
In the user's case the search is about
std::vector<reco::RecoTauPiZero>
but the argument found isvector<ROOT::Experimental::REveTableEntry>::size_type
which ends up with a batch job trying to loadlibREve
and thuslibGui
and thus requiring the reading of$HOME/.root.mimes
which fails badly if$HOME
is not set (case of somce condor jobs) which issues a Fatal error.The text was updated successfully, but these errors were encountered: