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

[John McCall via cfe-dev]

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, 
then
sure, most of those translation units are just checking for `RecordType` 
or
`PointerType`.

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