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