Spurrious auto parsing when looking up a TClass #17992
Comments
|
Tangentially related: |
pcanal
added a commit
to pcanal/roottest
that referenced
this issue
Mar 13, 2025
pcanal
added a commit
to pcanal/root
that referenced
this issue
Mar 13, 2025
If a library was loaded, the alias for a class were also loaded and a non normalized name might lead to a match. If we skip this check, then the next step will normalized the name and check for typedef inside the name (if it is a template instance name) and if the name are not found as is, it may lead to loading the header file. ie. this fixes root-project#17992 and cms-sw/cmssw#47470
dpiparo
added a commit
to dpiparo/roottest
that referenced
this issue
Mar 22, 2025
dpiparo
pushed a commit
to dpiparo/root
that referenced
this issue
Mar 22, 2025
If a library was loaded, the alias for a class were also loaded and a non normalized name might lead to a match. If we skip this check, then the next step will normalized the name and check for typedef inside the name (if it is a template instance name) and if the name are not found as is, it may lead to loading the header file. ie. this fixes root-project#17992 and cms-sw/cmssw#47470
dpiparo
pushed a commit
to dpiparo/root
that referenced
this issue
Mar 22, 2025
If a library was loaded, the alias for a class were also loaded and a non normalized name might lead to a match. If we skip this check, then the next step will normalized the name and check for typedef inside the name (if it is a template instance name) and if the name are not found as is, it may lead to loading the header file. ie. this fixes root-project#17992 and cms-sw/cmssw#47470
dpiparo
added a commit
to root-project/roottest
that referenced
this issue
Mar 22, 2025
dpiparo
pushed a commit
that referenced
this issue
Mar 23, 2025
If a library was loaded, the alias for a class were also loaded and a non normalized name might lead to a match. If we skip this check, then the next step will normalized the name and check for typedef inside the name (if it is a template instance name) and if the name are not found as is, it may lead to loading the header file. ie. this fixes #17992 and cms-sw/cmssw#47470
dpiparo
pushed a commit
that referenced
this issue
Mar 23, 2025
If a library was loaded, the alias for a class were also loaded and a non normalized name might lead to a match. If we skip this check, then the next step will normalized the name and check for typedef inside the name (if it is a template instance name) and if the name are not found as is, it may lead to loading the header file. ie. this fixes #17992 and cms-sw/cmssw#47470
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Check duplicate issues.
Description
As seen in cms-sw/cmssw#47470 in some circumstances calling
TClass::GetClassmay lead to an unnecessary/unwanted loading of the header files.Reproducer
In the example, there is a lookup for
vector<edm::Ref<vector<l1t::TkElectron>,l1t::TkElectron,edm::refhelper::FindUsingAdvance<vector<l1t::TkElectron>,l1t::TkElectron> > >which, because it is a normalized class name lead to a code path where we do
However in this case
edm::refhelper::FindUsingAdvance<vector<l1t::TkElectron>,l1t::TkElectron> >is intentionally not known to core/meta/TClass and thus the name normalization must check if it is a typedef and this step triggers the (auto) parsing of the headers (forl1t::TkElectron).This can be solved by executing between 1 and 2:
1a. check for dictionary with the name as is.
ROOT version
at least 6.32 up to master (probably more)
Installation method
any
Operating system
any
Additional context
No response
The text was updated successfully, but these errors were encountered: