Add null-type guards before QualType::getFromOpaquePtr

[aaronj0]

Some of these type-interfaces have missing null-guard, while others have them. In the ROOT-cppyy migration Ihit one such case with GetReferencedType. I took this opportunity to fond other places wehre this check would be good to have. Along with compiler-research/cppyy-backend#202, this enables 3 new root tests (stl_vector_iadd, rdataframe_misc gh_20291 and distrdf-proxy columninfo)

[vgvassilev]

I do not think this is a good change per se. In some cases if the input argument is nullptr it is unclear what is the right return value we should have. We can add non_null attributes to the function arguments but not early returns I guess.

[aaronj0]

I do not think this is a good change per se. In some cases if the input argument is nullptr it is unclear what is the right return value we should have. We can add non_null attributes to the function arguments but not early returns I guess.

Two points: 1. This is the same pattern we currently have accross the code base (return a value that would fail a conditional e.g if(Cpp::GetReferencedType(nullptr) is not true, false for bool, and so on)
2. If you don't have a type (i.e nullptr) then what else can you do besides early return with a non-true value?

I think for the APIs touched in this PR it is trivial.

[vgvassilev]

I do not think this is a good change per se. In some cases if the input argument is nullptr it is unclear what is the right return value we should have. We can add non_null attributes to the function arguments but not early returns I guess.

Two points: 1. This is the same pattern we currently have accross the code base (return a value that would fail a conditional e.g if(Cpp::GetReferencedType(nullptr) is not true, false for bool, and so on) 2. If you don't have a type (i.e nullptr) then what else can you do besides early return with a non-true value?

I think for the APIs touched in this PR it is trivial.

ValueKind GetValueKind(TCppType_t type) {
  INTEROP_TRACE(type);
  if (!type)
    return INTEROP_RETURN(nullptr);

That is one of the cases where returning is not the right answer.

TCppType_t GetPointerType(TCppType_t type) {
  INTEROP_TRACE(type);
  if (!type)
    return INTEROP_RETURN(nullptr);
  QualType QT = QualType::getFromOpaquePtr(type);
  return INTEROP_RETURN(getASTContext().getPointerType(QT).getAsOpaquePtr());
}

Here the question is the type of a nullptr type is QualType that returns "isNull" or the equivalent nullptr_t?

This is very hard to get it semantically right. We need to return std::optional or something else to express the intent you are trying to express. The interfaces should have been void& but that does not work. That is, we need to assume that nullptr is programmers error and assert. These will be irrelevant with the strong types PR that I have where we won't have such dilemma. I think here it is safe to assume for now that none of these interfaces should be called with a nullptr.