[lldb-dev] Compiler types and renamings

Ryan Brown via lldb-dev lldb-dev at lists.llvm.org
Thu Sep 17 10:14:03 PDT 2015


On Thu, Sep 17, 2015 at 10:06 AM Greg Clayton via lldb-dev <
lldb-dev at lists.llvm.org> wrote:

>
> > On Sep 17, 2015, at 3:08 AM, Bruce Mitchener <bruce.mitchener at 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 at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20150917/e41b7229/attachment.html>


More information about the lldb-dev mailing list