[ntuple] Propagate type aliases from item fields #20623
Open
+230
−48
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jblomer
force-pushed
the
ntuple-propagate-type-alias
branch
from
3ec064d to
934d6af
Compare
The variant field, the tuple field, and the pair field all use approximately the same GetTypeList() private static method. Factor this out in a single method in an anonymous namespace.
When constructing compound types from item fields, propagate alias types from the item fields to the parent field. This is already done globally in RFieldBase::Create() because the entire type name is compared to the unresolved type name. However, the type alias propagation was missing when a field is directly constructed with an item field.
Test Results 22 files 22 suites 3d 23h 39m 39s ⏱️ Results for commit 934d6af. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This should be the last piece to fix #20282. In particular, it is necessary to fix
[U]Long64_ttemplate arguments where the type is not wrapped in a class. I.e. without this fixAnother PR with the corresponding test will follow.
@makortel Please let me know if you need this backported to 6.36. This depends on whether your top-level branches are all wrapped in a class or if you have STL collections directly as top-level branches.