Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Spurrious auto parsing when looking up a TClass #17992

Open
1 task done
pcanal opened this issue Mar 13, 2025 · 1 comment · May be fixed by #17994
Open
1 task done

Spurrious auto parsing when looking up a TClass #17992

pcanal opened this issue Mar 13, 2025 · 1 comment · May be fixed by #17994
Assignees
@pcanal
Labels
bug in:Core Libraries in:I/O
Milestone
6.36.00

Comments

@pcanal
Copy link
Member

pcanal commented Mar 13, 2025

Check duplicate issues.

  • Checked for duplicates

Description

As seen in cms-sw/cmssw#47470 in some circumstances calling TClass::GetClass may 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

  1. auloading the library needed for this class and it dependencies
  2. attempt to normalize the name and resolve potential typedefs
  3. check for the dictionary.
    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 (for l1t::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
@pcanal pcanal self-assigned this Mar 13, 2025
@pcanal pcanal modified the milestones: 6.36.00, 6.34.06, 6.32.12 Mar 13, 2025
@ferdymercury
Copy link
Contributor

Tangentially related:
#14930 (comment)
#14760 (comment)

pcanal added a commit to pcanal/roottest that referenced this issue Mar 13, 2025
@pcanal
Test for root-project/root#17992
7177be0
@pcanal pcanal mentioned this issue Mar 13, 2025
Open
pcanal added a commit to pcanal/root that referenced this issue Mar 13, 2025
@pcanal
meta: After autoload, immediately check TClassTable.
3812e5e 
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
@pcanal pcanal linked a pull request Mar 13, 2025 that will close this issue
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@pcanal pcanal

Labels
bug in:Core Libraries in:I/O
Projects
Fixed in 6.36.00
Status: No status
Milestone
6.36.00
Development

Successfully merging a pull request may close this issue.

Fix spurrious auto parsing when looking up a TClass pcanal/root
2 participants
@pcanal @ferdymercury