Finding redundant #includes

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Finding redundant #includes

Andrew Price
Hi,

Can clang's analysis features help me find #includes which are no longer
required in a C source file? I'm working on cleaning up some old crufty
code and it would be good to have this functionality.

Andrew
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Finding redundant #includes

steve naroff
Hi Andrew,

I don't believe we currently have such a feature (though it's an  
interesting idea).

Implementing this wouldn't be too difficult, however it certainly  
isn't a "quick hack".

snaroff

On Dec 12, 2009, at 11:13 AM, Andrew Price wrote:

> Hi,
>
> Can clang's analysis features help me find #includes which are no  
> longer
> required in a C source file? I'm working on cleaning up some old  
> crufty
> code and it would be good to have this functionality.
>
> Andrew
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Finding redundant #includes

Andrew Price
On Sat, Dec 12, 2009 at 11:51:00AM -0500, steve naroff wrote:
> Hi Andrew,
>
> I don't believe we currently have such a feature (though it's an
> interesting idea).
>
> Implementing this wouldn't be too difficult, however it certainly
> isn't a "quick hack".

Sounds promising. I'm in no rush so if anybody would like me to test
patches for this feel free to send them my way.

Thanks,

Andrew
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Finding redundant #includes

Ted Kremenek
In reply to this post by steve naroff
Doing it correctly wouldn't be too hard from the AST perspective, but would be tricky when considering preprocessor logic.  Any macros defined in a header and later used outside that header causes a dependency.  Moreover, if a file can be compiled under different contexts, e.g., on Mac OS X one can compile for i386, x86_64, etc., then the "liveness" of a #include can change between translations.

On Dec 12, 2009, at 8:51 AM, steve naroff wrote:

> Hi Andrew,
>
> I don't believe we currently have such a feature (though it's an  
> interesting idea).
>
> Implementing this wouldn't be too difficult, however it certainly  
> isn't a "quick hack".
>
> snaroff
>
> On Dec 12, 2009, at 11:13 AM, Andrew Price wrote:
>
>> Hi,
>>
>> Can clang's analysis features help me find #includes which are no  
>> longer
>> required in a C source file? I'm working on cleaning up some old  
>> crufty
>> code and it would be good to have this functionality.
>>
>> Andrew
>> _______________________________________________
>> cfe-dev mailing list
>> [hidden email]
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Finding redundant #includes

steve naroff
Good points. I think the diagnostics would need some interpretation  
(by a human).

If we wanted to get "fancy", we could devise some way to determine if  
a declaration occurred within a #ifdef clause (special casing the  
#ifndef that is commonly at the begin/end of every C header).  
Unfortunately, any feature involving the preprocessor is usually more  
complex than it should be (given the ability to arbitrary mutate  
headers in different contexts...including the same compilation unit:-(

Fortunately, ObjC headers and user-defined (i.e. non-system) headers  
usually aren't as gross...

snaroff

On Dec 12, 2009, at 2:56 PM, Ted Kremenek wrote:

> Doing it correctly wouldn't be too hard from the AST perspective,  
> but would be tricky when considering preprocessor logic.  Any macros  
> defined in a header and later used outside that header causes a  
> dependency.  Moreover, if a file can be compiled under different  
> contexts, e.g., on Mac OS X one can compile for i386, x86_64, etc.,  
> then the "liveness" of a #include can change between translations.
>
> On Dec 12, 2009, at 8:51 AM, steve naroff wrote:
>
>> Hi Andrew,
>>
>> I don't believe we currently have such a feature (though it's an
>> interesting idea).
>>
>> Implementing this wouldn't be too difficult, however it certainly
>> isn't a "quick hack".
>>
>> snaroff
>>
>> On Dec 12, 2009, at 11:13 AM, Andrew Price wrote:
>>
>>> Hi,
>>>
>>> Can clang's analysis features help me find #includes which are no
>>> longer
>>> required in a C source file? I'm working on cleaning up some old
>>> crufty
>>> code and it would be good to have this functionality.
>>>
>>> Andrew
>>> _______________________________________________
>>> cfe-dev mailing list
>>> [hidden email]
>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>
>> _______________________________________________
>> cfe-dev mailing list
>> [hidden email]
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Finding redundant #includes

Ted Kremenek
Just a thought: I wonder if for top-level #includes, one possibility is to remove the #include and see if it produces the same translation afterwards in the main source file.  That would avoid the issues with explicitly reasoning about preprocessor logic, and would (I believe) handle the simplest case that people care about.

On Dec 12, 2009, at 12:26 PM, steve naroff wrote:

> Good points. I think the diagnostics would need some interpretation (by a human).
>
> If we wanted to get "fancy", we could devise some way to determine if a declaration occurred within a #ifdef clause (special casing the #ifndef that is commonly at the begin/end of every C header). Unfortunately, any feature involving the preprocessor is usually more complex than it should be (given the ability to arbitrary mutate headers in different contexts...including the same compilation unit:-(
>
> Fortunately, ObjC headers and user-defined (i.e. non-system) headers usually aren't as gross...
>
> snaroff
>
> On Dec 12, 2009, at 2:56 PM, Ted Kremenek wrote:
>
>> Doing it correctly wouldn't be too hard from the AST perspective, but would be tricky when considering preprocessor logic.  Any macros defined in a header and later used outside that header causes a dependency.  Moreover, if a file can be compiled under different contexts, e.g., on Mac OS X one can compile for i386, x86_64, etc., then the "liveness" of a #include can change between translations.
>>
>> On Dec 12, 2009, at 8:51 AM, steve naroff wrote:
>>
>>> Hi Andrew,
>>>
>>> I don't believe we currently have such a feature (though it's an
>>> interesting idea).
>>>
>>> Implementing this wouldn't be too difficult, however it certainly
>>> isn't a "quick hack".
>>>
>>> snaroff
>>>
>>> On Dec 12, 2009, at 11:13 AM, Andrew Price wrote:
>>>
>>>> Hi,
>>>>
>>>> Can clang's analysis features help me find #includes which are no
>>>> longer
>>>> required in a C source file? I'm working on cleaning up some old
>>>> crufty
>>>> code and it would be good to have this functionality.
>>>>
>>>> Andrew
>>>> _______________________________________________
>>>> cfe-dev mailing list
>>>> [hidden email]
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>>
>>> _______________________________________________
>>> cfe-dev mailing list
>>> [hidden email]
>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>
>


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Finding redundant #includes

Chandler Carruth
On Sat, Dec 12, 2009 at 1:01 PM, Ted Kremenek <[hidden email]> wrote:
> Just a thought: I wonder if for top-level #includes, one possibility is to remove the #include and see if it produces the same translation afterwards in the main source file.  That would avoid the issues with explicitly reasoning about preprocessor logic, and would (I believe) handle the simplest case that people care about.

For reference, we do this and have found it be effective, especially
combined with a distributed compilation framework which can do even
the preprocessing phase
(http://google-opensource.blogspot.com/2008/08/distccs-pump-mode-new-design-for.html).
I'd be interested if there are less expensive ways to achieve these
results though.

>
> On Dec 12, 2009, at 12:26 PM, steve naroff wrote:
>
>> Good points. I think the diagnostics would need some interpretation (by a human).
>>
>> If we wanted to get "fancy", we could devise some way to determine if a declaration occurred within a #ifdef clause (special casing the #ifndef that is commonly at the begin/end of every C header). Unfortunately, any feature involving the preprocessor is usually more complex than it should be (given the ability to arbitrary mutate headers in different contexts...including the same compilation unit:-(
>>
>> Fortunately, ObjC headers and user-defined (i.e. non-system) headers usually aren't as gross...
>>
>> snaroff
>>
>> On Dec 12, 2009, at 2:56 PM, Ted Kremenek wrote:
>>
>>> Doing it correctly wouldn't be too hard from the AST perspective, but would be tricky when considering preprocessor logic.  Any macros defined in a header and later used outside that header causes a dependency.  Moreover, if a file can be compiled under different contexts, e.g., on Mac OS X one can compile for i386, x86_64, etc., then the "liveness" of a #include can change between translations.
>>>
>>> On Dec 12, 2009, at 8:51 AM, steve naroff wrote:
>>>
>>>> Hi Andrew,
>>>>
>>>> I don't believe we currently have such a feature (though it's an
>>>> interesting idea).
>>>>
>>>> Implementing this wouldn't be too difficult, however it certainly
>>>> isn't a "quick hack".
>>>>
>>>> snaroff
>>>>
>>>> On Dec 12, 2009, at 11:13 AM, Andrew Price wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Can clang's analysis features help me find #includes which are no
>>>>> longer
>>>>> required in a C source file? I'm working on cleaning up some old
>>>>> crufty
>>>>> code and it would be good to have this functionality.
>>>>>
>>>>> Andrew
>>>>> _______________________________________________
>>>>> cfe-dev mailing list
>>>>> [hidden email]
>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>>>
>>>> _______________________________________________
>>>> cfe-dev mailing list
>>>> [hidden email]
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>>
>>
>
>
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Finding redundant #includes

Andrew Price
In reply to this post by Andrew Price
I have opened a bug to track this feature request:

http://llvm.org/bugs/show_bug.cgi?id=5782

Andrew
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Finding redundant #includes

Daniel Dunbar
In reply to this post by Ted Kremenek
On Sat, Dec 12, 2009 at 1:01 PM, Ted Kremenek <[hidden email]> wrote:
> Just a thought: I wonder if for top-level #includes, one possibility is to remove the #include and see if it produces the same translation afterwards in the main source file.  That would avoid the issues with explicitly reasoning about preprocessor logic, and would (I believe) handle the simplest case that people care about.

Yes, I think this would be a sane and pretty strong approach. It
requires a good way to compare ASTs, which we don't have.

There is a lot of utility in removing includes in non-main fails, as
well, of course.

 - Daniel

> On Dec 12, 2009, at 12:26 PM, steve naroff wrote:
>
>> Good points. I think the diagnostics would need some interpretation (by a human).
>>
>> If we wanted to get "fancy", we could devise some way to determine if a declaration occurred within a #ifdef clause (special casing the #ifndef that is commonly at the begin/end of every C header). Unfortunately, any feature involving the preprocessor is usually more complex than it should be (given the ability to arbitrary mutate headers in different contexts...including the same compilation unit:-(
>>
>> Fortunately, ObjC headers and user-defined (i.e. non-system) headers usually aren't as gross...
>>
>> snaroff
>>
>> On Dec 12, 2009, at 2:56 PM, Ted Kremenek wrote:
>>
>>> Doing it correctly wouldn't be too hard from the AST perspective, but would be tricky when considering preprocessor logic.  Any macros defined in a header and later used outside that header causes a dependency.  Moreover, if a file can be compiled under different contexts, e.g., on Mac OS X one can compile for i386, x86_64, etc., then the "liveness" of a #include can change between translations.
>>>
>>> On Dec 12, 2009, at 8:51 AM, steve naroff wrote:
>>>
>>>> Hi Andrew,
>>>>
>>>> I don't believe we currently have such a feature (though it's an
>>>> interesting idea).
>>>>
>>>> Implementing this wouldn't be too difficult, however it certainly
>>>> isn't a "quick hack".
>>>>
>>>> snaroff
>>>>
>>>> On Dec 12, 2009, at 11:13 AM, Andrew Price wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Can clang's analysis features help me find #includes which are no
>>>>> longer
>>>>> required in a C source file? I'm working on cleaning up some old
>>>>> crufty
>>>>> code and it would be good to have this functionality.
>>>>>
>>>>> Andrew
>>>>> _______________________________________________
>>>>> cfe-dev mailing list
>>>>> [hidden email]
>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>>>
>>>> _______________________________________________
>>>> cfe-dev mailing list
>>>> [hidden email]
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>>
>>
>
>
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Loading...