On Thu, Sep 17, 2015 at 10:06 AM Greg Clayton via lldb-dev < lldb-dev@lists.llvm.org> wrote:
> > > On Sep 17, 2015, at 3:08 AM, Bruce Mitchener <bruce.mitche...@gmail.com> > wrote: > > > > Howdy! > > > > I was looking at some of the CompilerType changes and had some questions > related to the recent cleanups and renamings. > > > > • 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? > > 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. > > > • 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? > > 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... > Actually the DWARFASTParserGo is using this too. Is that a problem? It seems like each die should only be associated with one compile unit and hence one type system. > > > • 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. > > Yes! please do make the change to fix this. > > > 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. > > So please do the first and last and skip the DIEToClangType/ClangTypeToDIE > cleanup. > > Greg > > _______________________________________________ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev