Repository navigation
Conversation
A std::string executor may hand back a Python str rather than a proxy;
op_str cast the result to CPPInstance unconditionally and read through
it. Take the text from either shape, and treat the generic
"{not representable}" fallback like an address-only result so op_str
falls through to the generic repr.
67275a4 to
ac9d79c
Compare
|
Is this worth a test? |
Currently we can't assert that in the upstream test suite since it's only on the ROOT side that cppjit always converted the returned value to Python string. Here is the patch: root-project/root@5a4bbac which, even before the migration, was tracked against cppyy. I do not think that behaviour is something upstreamable for now, but what this patch does is protect us with a check instead of assuming that the return value is a CppInstance of std::string and crashing. |
Isn’t the last statement contradicting the first? If we can trigger this only through a ROOT patch that is not upstreamable why upstreaming dead code. |
A std::string executor may hand back a Python str rather than a proxy. In ROOT's case we always return a Python str.
op_strcast the result to CPPInstance unconditionally and read through it. Take the text from either shape, and treat the generic "{not representable}" fallback as in the case of an address-only result, so op_str falls through to the generic repr instead of crashing.