[ntuple] Check type in RValue::GetRef<T> and GetPtr<T>

[hahnjo]

This requires splitting RValue and RBulkValues into a separate header. After the changes, the organization is as follows:

• RFieldBase.hxx: defines RFieldBase and forward-declares RFieldBase::RValue and RFieldBase::RBulkValues
• RField.hxx: includes RFieldBase.hxx and defines RField<T> with all specializations; they provide RField<T>::TypeName()
• RFieldBaseRValue.hxx: includes both RFieldBase.hxx and RField.hxx, defines RValue and RBulkValues; the typed API uses RField<T>::TypeName()

Closes #18316

[github-actions]

Test Results

    21 files      21 suites   3d 12h 14m 52s ⏱️
 3 203 tests  3 203 ✅ 0 💤 0 ❌
65 606 runs  65 606 ✅ 0 💤 0 ❌

Results for commit 6742820.

♻️ This comment has been updated with latest results.

[enirolf]

I think the error message could be a bit more descriptive, maybe something like:

Suggested change

	R__FAIL("type mismatch: " + fField->GetTypeName() + " vs. " + ROOT::RField<T>::TypeName()));
	R__FAIL("type mismatch for field \"" + fField->GetFieldName + "\": expected " + fField->GetTypeName() + ", got " + ROOT::RField<T>::TypeName()));

[jblomer]

Nice! Since this can break user code, I think we add an entry to the release notes.

[jblomer]

When #19323 is merged, I think we want to use ROOT::Internal::IsMatchingFieldType. So maybe schedule the two PRs one after the other?

[hahnjo]

Yes right, and we probably also want to extend roottest/root/ntuple/atlas-datavector/ to check that the procedure is working. Let's pause this PR for the moment and focus on #19323 which seems close to done.

[jblomer]

Since this anyway covers both RValue and RBulkValues, how about calling the header RFieldBaseValue.hxx? I think it would look slightly nicer to me.

[jblomer]

Thinking again about it: there is a possible alternative solution using a new, internal helper class, e.g. RFieldTypeName<T>. This class would only take care of the type name and would be used both by RField<T> and RValue. The drawback is that we need to duplicate the template specializations for the new helper class but the advantage is that we don't change the user-visible includes.

[hahnjo]

Thinking again about it: there is a possible alternative solution using a new, internal helper class, e.g. RFieldTypeName<T>. This class would only take care of the type name and would be used both by RField<T> and RValue. The drawback is that we need to duplicate the template specializations for the new helper class but the advantage is that we don't change the user-visible includes.

Yes, it's a possibility. However, it probably requires duplicating (some of) RIntegralField and RIntegralTypeMap. We can give it a try and see if we like it better.