Compiler types and renamings

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?

  • 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?

  • 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.

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.

  • Bruce
    Part time code janitor

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...

  • 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

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.

Yes that is a problem if there is ever mixed Go and C/C++/ObjC in one binary. I would switch DWARFASTParserGo() to have its own cache and use it.

Greg