<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, Sep 17, 2015 at 10:06 AM Greg Clayton via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org">lldb-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On Sep 17, 2015, at 3:08 AM, Bruce Mitchener <<a href="mailto:bruce.mitchener@gmail.com" target="_blank">bruce.mitchener@gmail.com</a>> wrote:<br>
><br>
> Howdy!<br>
><br>
> I was looking at some of the CompilerType changes and had some questions related to the recent cleanups and renamings.<br>
><br>
>       • clang_type_t is a typedef for void* and is used for the opaque qual type code among other things. However, the m_type on CompilerType is just a void*.  Should we rename clang_type_t to compiler_type_t or just do away with it and use void* instead?<br>
<br>
It might be a good idea to use something like "compiler_opaque_type_t" or just "opaque_t", which is a typedef to "void *". Then we can use this to CompilerDecl, CompilerDeclContext and CompilerType.<br>
<br>
>       • SymbolFileDWARF has 2 typedefs, DIEToClangType and ClangTypeToDIE which are used for 2 maps, m_forward_decl_die_to_clang_type and m_forward_decl_clang_type_to_die. Should these be renamed to use Compiler instead of Clang?<br>
<br>
They could be, but I really need to move these DIEToClangType and ClangTypeToDIE over into DWARFASTParserClang. The problem it is isn't saving the entire CompilerType it is just saving the clang_type_t and some other type system, like Go's TypeSystem, could actually make a CompilerType and use its type system and this "void *"... So this map is really just for Clang types. The reason it wasn't moved was we only have one DWARFASTParserClang when we have DWARF in .o files on MacOSX (we have a "a.out" executable and it points to N SymbolFileDWARF instances (one for each .o file where the .o files contain DWARF, but there is no DWARF in the main executable) so I didn't want to move this map over into DWARFASTParserClang since this would change things. So I vote to not rename it for now and let users know this is for clang types only...<br></blockquote><div><br></div><div>Actually the DWARFASTParserGo is using this too.</div><div>Is that a problem? It seems like each die should only be associated with one compile unit and hence one type system.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
>       • Any use of an instance of CompilerType in general code (code not in a file with Clang in the name) can probably be renamed from clang_type to compiler_type, right? This would include the clang_type member on Type.<br>
<br>
Yes! please do make the change to fix this.<br>
<br>
> I'd like to do any of the above, just want to make sure that it won't clash with pending changes like this and that people actually want this to happen.<br>
<br>
So please do the first and last and skip the DIEToClangType/ClangTypeToDIE cleanup.<br>
<br>
Greg<br>
<br>
_______________________________________________<br>
lldb-dev mailing list<br>
<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev</a><br>
</blockquote></div></div>