[llvm-dev] Splitting up Type.h: Good idea, bad idea?

John McCall via llvm-dev llvm-dev at lists.llvm.org
Tue Apr 7 13:54:19 PDT 2020

On 7 Apr 2020, at 16:18, Reid Kleckner wrote:
> On Tue, Apr 7, 2020 at 11:35 AM Chris Lattner <clattner at nondot.org> 
> wrote:
>> +cfe-dev.
> Sorry about it going to llvm-dev. I typed cfe-dev<enter> into the To: 
> box
> and got llvm-dev.
>> Splitting this header up makes sense to me.  Types.h was not intended 
>> to
>> be the 7000 line monster it is now :-).
>> Splitting QualType out to its own header makes a lot of sense to me, 
>> but
>> would it make sense to further split it up somehow?  For example, one 
>> could
>> split the C-like types, from the C++-like types, from the extensions. 
>>  I’m
>> not sure if that would be useful though.
> I think that's a good idea. I think there are some key types that 
> everyone
> uses (ReferenceType, PointerType, FunctionType). The Decl and Stmt 
> class
> hierarchy currently often use these types from inline methods.
> On Tue, Apr 7, 2020 at 10:34 AM John McCall <rjmccall at apple.com> 
> wrote:
>> How many translation units actually don’t ultimately need the type
>> definitions?  Because this achieves nothing if almost every 
>> translation
>> unit ends up including Type.h anyway.
> It's hard to know this without doing it. My plan was to do it, hope to 
> get
> early good results, and use that to motivate finishing the project. 
> But, my
> lack of results is making me reconsider the whole project.
> The IWYU tool exists, but the results are generally considered 
> unusable. We
> could try to run it on the codebase and see how often it thinks Type.h
> should be included. Part of the project is refactoring the code to not 
> use
> Type.h.

My guess would be that 90% or more of the translation units that depend
on the AST end up doing some type-specific analysis and so will need the
full `Type.h` anyway.  Now, if you break `Type.h` up into the C base, 
sure, most of those translation units are just checking for `RecordType` 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200407/84bc8358/attachment.html>

More information about the llvm-dev mailing list