Open pcanal opened 1 year ago
We should not use the internal names here, but dedicated ROOT I/O attribute names.
If that's not possible then we should at least allow for future cling attributes that are not I/O comments, i.e. some form of scoping of attribute names. (And yes I now see that you already stated that, sorry!)
If/when we officially support the annotation as input we need to resolve/decide/do-something the potential conflict between the input from comments, selection xml and the annotation.
How do you deal now with conflicts between the comments and the xml selection ?
Currently genreflex
(mostly) wins. The comment
tag has priority over the comment in the C++ code but the transient
and persistent
tag do not.
And for completeness sake's, currently the clang::annotate
wins over both.
As seen in https://github.com/cms-sw/cmssw/pull/40435, ROOT I/O annotation can be moved from the comments to using
C++ attributes
(in particular because support for the comment is implemented internally through the same mechanics).To quote the referred pull request:
The way dictionary information are propagated from the
C++
code orXML
dictionaries to reflex and cling is rather roundabout:<field name="data_" comment="!"/>
tagsXML
dictionaries are parsed bygenreflex
and injected into theLLVM AST
of the correspondingC++
code as comments//!
;C++
comments like//!
or//[size_]
are converted bygenreflex/rootcling
intoLLVM AST
annotations; cling parses theLLVM
annotations and uses them to generate the desired behavior in the dictionaries.This approach does not work well with macro-generated data members:
//!
or//[size_]
cannot be used directly;class_def.xml
file, requiring manual intervention for their implementation and maintenance.However, it turns out that dictionaries can bypass the comments and use LLVM annotations directly within the C++ code. So
can be also expressed as
and annotations can be generated by macros.
In order to avoid spurious warnings when compiling the header, we should offer a (set of) macro(s), eg:
ROOT_IO_TRANSIENT
can be used to annotate transient data members, like `//!ROO_IO_SIZE(SIZE)
can be used to annotate dynamic arrays, like//[SIZE]
orROOT_IO_ANNOTATE
that can be used withROOT_IO_ANNOATE("!")
andROOT_IO_ANNOTATE("[size]")
The advantage of the earlier case would be to (possibly) allow simplification of the internal parsing, by using: