STL PMR data structures are not correctly parsed

[hexomethyl]

Cppyy seems to fail to correctly handle the PMR type aliases for both Unordered and ordered STL maps when either the key or value also contains the PMR namespace. Below are test cases which seem to fail.

def test_cppyy_pmr():
    try:
        cppyy.gbl.__cppyy_testing.TestObjectPmr
    except:
        cppyy.cppdef(
        """
        #include <memory_resource>
        #include <string>
        #include <memory>
        #include <unordered_map>
        #include <map>
        #include <cstdint>
        
        namespace __cppyy_testing {
            struct TestObjectPmr {
                struct NestedDummyObject {
                    std::int32_t id;
                };
                
                std::pmr::unordered_map<std::pmr::string, std::unique_ptr<NestedDummyObject>> umap;
                std::pmr::unordered_map<std::string, std::shared_ptr<NestedDummyObject>> map;
            };
        }
        """
        )

    obj = cppyy.gbl.__cppyy_testing.TestObjectPmr()

umap ends up with the incorrect type of cppyy.gbl.std.unordered_map<std::stringtd::pmr::polymorphic_allocator<char>,std::unique_ptr<__cppyy_testing::TestObjectPmr::N...jectPmr::NestedDummyObject,std::default_delete<__cppyy_testing::TestObjectPmr::NestedDummyObject>>>>> where std::pmr::string is malformed.

map has the correct type but I cannot seem to insert any data into the map

[hexomethyl]

namespace __cppyy_testing {
          struct TestObjectPmr {
              struct NestedDummyObject {
                  std::int32_t id;
              };
              
              std::pmr::unordered_map<std::pmr::string, std::int32_t> umap;
              std::pmr::unordered_map<std::string, std::int32_t> map;
          };
      }

For the code presented above, the map structure works as expected, however umap fails due to not receiving any of Cppyy STL pythonizations

[wlav]

My bet is on the ROOT/meta legacy code. That code was written when upstream was still doing using namespace std everywhere. The meta code attempts to normalize type names by always representing std::basic_string<> as std::string, but b/c of that prior using namespace std, it may be going too eagerly after anything that is called string, then just removes parts of the name w/o checking.

With the normalized name messed up, I'm sure iterator, value types, etc. can't be found, so no pythonizations. (Aside, although the name ends up incorrect on Linux, on Mac the code actually segfaults.)

Meta is a maze (there's an on-going effort by upstream to get rid of it). May take a bit to find where things are going wrong.