Dictionary is missing a class' alternate spelling if the normalized name is requested first.

[pcanal]

The following issue was discovered by CMS when investigating why disabling header auto-parsing during TClass::GetClass lead to a failure. The failures were due to a I/O customization rule not being run because the rule's source data member is listed using the alternate class name.

When a linkdef.h or selection.xml contains 2 requests for the same entity only the first seen in taken in consideration. This has the drawback of not registering aliases for a type even-though they have been explicitly requested.
For example with:

struct TestStruct {};
struct Holder { using Product = TestStruct; };

and

#pragma link C++ class TestStruct+;
#pragma link C++ class Holder::Product+;

then

TClass::GetClass("Holder::Product")

will only succeed if the header file is parsed. Inverting the 2 #pragma line or removing the first one will solve the problem.

A more complete reproducer is in the following file: typedef_and_dict_order.tar.gz
The dictionary and rootmap files can be regenarated by running the go script.
The problem can be seen by doing grep:

jupyter-pcanal-rootdevel:nested pcanal$ grep 'portabletest::TestHostObject::Product' dict_typedef.cxx 
70:      instance.AdoptAlternate(::ROOT::AddClassAlternate("portabletest::TestStruct","portabletest::TestHostObject::Product"));
294:"portabletest::TestHostObject::Product", payloadCode, "@",
jupyter-pcanal-rootdevel:nested pcanal$ grep 'portabletest::TestHostObject::Product' dict_both.cxx 
70:      instance.AdoptAlternate(::ROOT::AddClassAlternate("portabletest::TestStruct","portabletest::TestHostObject::Product"));
294:"portabletest::TestHostObject::Product", payloadCode, "@",
jupyter-pcanal-rootdevel:nested pcanal$ grep 'portabletest::TestHostObject::Product' dict_reversed.cxx 

where the alias is missing in the file dict_reversed.cxx.

One can also look at the rootmap file:

grep -c 'portabletest::TestHostObject::Product' *.rootmap
port_both.rootmap:1
port_reversed.rootmap:0
port_typedef.rootmap:1

[pcanal]

Instead of ignoring the second rule, rootcling should be adding the alternate name to the list of aliases for the class.

[dpiparo]

The current behaviour is not what one would intuitively expected. If a typedef is selected, its name and the name of the underlying class appear in the rootmap. If the underlying class and the typedef are selected in this order, the name of the typedef does not appear in the rootmap. If the order the rules of this latter case is reversed, again both names appear in the rootmap.

[makortel]

Seems like CMS sees another face of this issue in the form (or in the context) of memory increase with ROOT 6.36 cms-sw/cmssw#49399

[srimanob]

@makortel @dpiparo
Do I understand correctly that the current fix we implemented is to go around this issue, but we still expect ROOT to fix? Thx.

[makortel]

Yes, the present setup is quite brittle, so we want this fixed in ROOT.