<div dir="ltr">Hi Hal,<div><br></div><div>as Philippe mentioned the patch is used to force through sugar nodes through template instantiation.</div><div>I think for the ROOT use case, one needs to be careful to only think about this in the context of starting from</div><div>of fields of a class/struct. I don't think ROOT has any problem with re-doing the template instantiation when</div><div>it needs to compute the disk layout, but we would need to be sure that all the required information is indeed</div><div>retained and that there is an API for doing so.</div><div><br></div><div>Keno</div><div><br></div><div><div class="gmail_extra"><div class="gmail_quote">On Tue, Jul 26, 2016 at 2:40 PM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">----- Original Message -----<br>
> From: "Keno Fischer via cfe-dev" <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>><br>
> To: "Reid Kleckner" <<a href="mailto:rnk@google.com">rnk@google.com</a>><br>
> Cc: "clang developer list" <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>><br>
> Sent: Tuesday, July 26, 2016 1:02:40 PM<br>
> Subject: Re: [cfe-dev] Recovering the spelling of a typedef<br>
><br>
> Yes, in the very simple cases, no patch is needed, but yes, ROOT<br>
> needs<br>
> to be able to look through templates which is where the problem comes<br>
> in.<br>
<br>
</span>What does your patch do?<br>
<br>
The core problem here is that if you have:<br>
<span class=""><br>
> > typedef double Double32_t;<br>
> > template <typename T> struct Bar { T f; };<br>
> > template struct Bar<Double32_t>;<br>
<br>
</span>then Bar<Double32_t> and Bar<double> have the same instantiation. You can have lots of different names from many different contexts. How many of these do you track and which name do you want to use?<br>
<br>
 -Hal<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> On Tue, Jul 26, 2016 at 1:40 PM, Reid Kleckner <<a href="mailto:rnk@google.com">rnk@google.com</a>><br>
> wrote:<br>
> > In simple cases, this information is already available as type<br>
> > sugar nodes.<br>
> > Consider this AST dump:<br>
> ><br>
> > typedef double Double32_t;<br>
> > struct Foo { Double32_t f; };<br>
> ><br>
> > |-TypedefDecl 0xd3af50 <t.cpp:1:1, col:16> col:16 referenced<br>
> > |Double32_t<br>
> > 'double'<br>
> > | `-BuiltinType 0xd09d50 'double'<br>
> > `-CXXRecordDecl 0xd3afa0 <line:2:1, col:28> col:8 struct Foo<br>
> > definition<br>
> >   |-CXXRecordDecl 0xd3b0c0 <col:1, col:8> col:8 implicit struct Foo<br>
> >   `-FieldDecl 0xd3b190 <col:14, col:25> col:25 f<br>
> >   'Double32_t':'double'<br>
> ><br>
> > Template instantiation uses the canonical, desugared types, though.<br>
> > You can<br>
> > see it from this dump:<br>
> ><br>
> > typedef double Double32_t;<br>
> > template <typename T> struct Bar { T f; };<br>
> > template struct Bar<Double32_t>;<br>
> ><br>
> > `-ClassTemplateSpecializationDecl 0xc3b490 <line:3:1, col:31><br>
> > col:17 struct<br>
> > Bar definition<br>
> >   |-TemplateArgument type 'double'<br>
> >   |-CXXRecordDecl 0xc3b688 prev 0xc3b490 <line:2:23, col:30> col:30<br>
> >   |implicit<br>
> > struct Bar<br>
> >   `-FieldDecl 0xc3b758 <col:36, col:38> col:38 f 'double':'double'<br>
> ><br>
> > Does ROOT need a way to push the type sugar nodes through template<br>
> > instantiation? I seem to recall that there are reasons why it's<br>
> > hard to do<br>
> > that from an implementation standpoint, but it would also help us<br>
> > get better<br>
> > diagnostics when rinsing "std::string" through a template type<br>
> > parameter,<br>
> > for example.<br>
> ><br>
> > On Tue, Jul 26, 2016 at 9:58 AM, Keno Fischer<br>
> > <<a href="mailto:kfischer@college.harvard.edu">kfischer@college.harvard.edu</a>><br>
> > wrote:<br>
> >><br>
> >> Yes, precisely. I am not fully versed in the details (Axel,<br>
> >> Philippe,<br>
> >> please correct any inaccuracies), but essentially you can request<br>
> >> an object<br>
> >> to be written to/ read from disk and ROOT will look up the<br>
> >> corresponding<br>
> >> class and compute the appropriate disk format (for which it needs<br>
> >> to<br>
> >> distinguish between double/Double32_t for any members). ROOT use a<br>
> >> C++<br>
> >> Interpreter/JIT (custom one for a very long time, transitioning to<br>
> >> LLVM/Clang) for interactivity and introspection, so it has the<br>
> >> ASTs for all<br>
> >> classes in the system available.<br>
> >><br>
> >> On Tue, Jul 26, 2016 at 12:36 PM, Reid Kleckner <<a href="mailto:rnk@google.com">rnk@google.com</a>><br>
> >> wrote:<br>
> >>><br>
> >>> Can you elaborate on how this typedef information is used for<br>
> >>> I/O? Do you<br>
> >>> mean that it is used by some clang plugin that examines the AST,<br>
> >>> or<br>
> >>> something else?<br>
> >>><br>
> >>> On Mon, Jul 25, 2016 at 6:55 PM, Keno Fischer via cfe-dev<br>
> >>> <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br>
> >>>><br>
> >>>> Hi Everyone,<br>
> >>>><br>
> >>>> We're trying to integrate the CERN ROOT framework with Julia,<br>
> >>>> both<br>
> >>>> of which use LLVM/Clang for C++ interoperability. As such, we're<br>
> >>>> hoping<br>
> >>>> to harmonize the versions of clang used in both projects. One<br>
> >>>> major<br>
> >>>> obstacle to this currently is a patch that the ROOT folks are<br>
> >>>> carrying<br>
> >>>> to support their I/O system which uses the structure of C++<br>
> >>>> classes to<br>
> >>>> determine the on-disk format. The patch as is isn't really in a<br>
> >>>> form<br>
> >>>> that could be submitted upstream, but we're hoping to solicit<br>
> >>>> some<br>
> >>>> advice<br>
> >>>> to come up with a solution that would be acceptable to clang,<br>
> >>>> and not<br>
> >>>> require any local code patches.<br>
> >>>><br>
> >>>> With that in mind, let us describe the problem:<br>
> >>>><br>
> >>>> As mentioned, ROOT uses the structure of C++ classes to<br>
> >>>> determine it's<br>
> >>>> IO format. The one wrinkle to that is that sometimes the I/O<br>
> >>>> storage<br>
> >>>> format and the in-memory format are not exactly the same. In<br>
> >>>> particular,<br>
> >>>> ROOT has a<br>
> >>>><br>
> >>>> typedef double Double32_t;<br>
> >>>><br>
> >>>> where if this typedef appears in a struct that is serialized to<br>
> >>>> disk,<br>
> >>>> it indicates that it should be stored with 32bit precision on<br>
> >>>> disk, but<br>
> >>>> with 64bit precision in memory.<br>
> >>>><br>
> >>>> That's *only* for I/O information; for anything regarding<br>
> >>>> symbols we<br>
> >>>> need these two to share their instantiation data.<br>
> >>>><br>
> >>>> I.e. we want to distinguish the types of D<double>::m and<br>
> >>>> D<Double32_t>::m (and also D<vector<Double32_t>>::m and<br>
> >>>> D<vector<double>>::m) in<br>
> >>>><br>
> >>>> template <class T><br>
> >>>> struct D {<br>
> >>>> using type = std::remove_reference<D>;<br>
> >>>> T m;<br>
> >>>> static int s;<br>
> >>>> };<br>
> >>>><br>
> >>>> But &D<double>::s must the the same as D<Double32_t>::s; more<br>
> >>>> importantly:<br>
> >>>><br>
> >>>> void f(D<double>);<br>
> >>>><br>
> >>>> must be called by f(D<Double32_t>{}). That is (IIRC) in contrast<br>
> >>>> of what<br>
> >>>> the C++ committee discussed for strong typedefs.<br>
> >>>><br>
> >>>> _______________________________________________<br>
> >>>> cfe-dev mailing list<br>
> >>>> <a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
> >>>> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
> >>>><br>
> >>><br>
> >><br>
> ><br>
> _______________________________________________<br>
> cfe-dev mailing list<br>
> <a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
><br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
Hal Finkel<br>
Assistant Computational Scientist<br>
Leadership Computing Facility<br>
Argonne National Laboratory<br>
</font></span></blockquote></div><br></div></div></div>