TCling::GetAutoParseClasses (and its Print counterpart) only provides the list of class name that directly triggered the auto-parsing of header files.
As seen in cms-sw/cmssw#49458 (see around cms-sw/cmssw#49458 (comment)), sometimes this is not the name of the class for which we are missing a dictionary.
For example we could have a class template sometemplate with 2 arguments and where the 2nd argument is irrelevant to I/O (does not participate in I/O, does not affect the I/O layout of the class template instance).
In such a case, the user would request the dictionary for the first argument and for the template instance.
In the error case (only have the dictionary for class A but inadvertently not for sometemplate<A, B> and intentionally not for B.
In that case the capture of the trigger of the auto-parsing will happen in the stack trace like:
- GetClass("sometemplate<A, B>");
- Successful auto-parse of B which also makes "sometemplate<A, B>" available.
In the CMS' case B is complex enough that the auto-parse can succeed even without a dictionary for the actual B (which is a class instance).
The auto-parse report would in this case only mention B (which is expected to not have a dictionary) where as the user need to know about sometemplate<A, B> in order to fix the proper missing dictionary.
To solve this issue the auto-parse report would need to gather the list of classes being looked up (by a TClass::GetClass) when an auto-parse happens.
One challenge is to minimize the impact of the common case (no error and no reporting needed) - This may or may not require to make the recording optional.
TCling::GetAutoParseClasses(and itsPrintcounterpart) only provides the list of class name that directly triggered the auto-parsing of header files.As seen in cms-sw/cmssw#49458 (see around cms-sw/cmssw#49458 (comment)), sometimes this is not the name of the class for which we are missing a dictionary.
For example we could have a class template
sometemplatewith 2 arguments and where the 2nd argument is irrelevant to I/O (does not participate in I/O, does not affect the I/O layout of the class template instance).In such a case, the user would request the dictionary for the first argument and for the template instance.
In the error case (only have the dictionary for class
Abut inadvertently not forsometemplate<A, B>and intentionally not forB.In that case the capture of the trigger of the auto-parsing will happen in the stack trace like:
In the CMS' case
Bis complex enough that the auto-parse can succeed even without a dictionary for the actualB(which is a class instance).The auto-parse report would in this case only mention
B(which is expected to not have a dictionary) where as the user need to know aboutsometemplate<A, B>in order to fix the proper missing dictionary.To solve this issue the auto-parse report would need to gather the list of classes being looked up (by a
TClass::GetClass) when an auto-parse happens.One challenge is to minimize the impact of the common case (no error and no reporting needed) - This may or may not require to make the recording optional.