search

HaveF / include-what-you-use

Automatically exported from code.google.com/p/include-what-you-use
Other
0 stars 0 forks source link

Support for Objective-C #47

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
From reading the documentation pages, I get the impression that iwyu currently 
only supports pure C and C++ files. This ticket is to request the ability to 
run iwyu on Objective-C and Objective-C++ files as well.

Real Objective-C code almost exclusively uses #import, so iwyu would need to 
support #import as well as #include. The two are not entirely synonymous: 
Unlike #include, which splices the named file into the source code every time, 
#import remembers files it has encountered before, and will only splice the 
file into the source code the first time. I'm not sure whether this detail 
would be significant to iwyu, but I include it in case it would.

#import is technically a separate extension to C, available in pure C files as 
well on Apple's platforms, so, ideally, support for #import should not be 
restricted to Objective-C code.

In Objective-C headers, it may be appropriate to move an #import of another 
class's header to the module file and replace it in the header with an @class 
declaration. However, this cannot be done unconditionally: There are some 
occasional cases where a header really does need to import another header, most 
especially for superclasses. @class can be used when the only uses of the class 
name(s) are in variable and property declarations.

Original issue reported on code.google.com by boredzo on 3 Jul 2011 at 5:59

GoogleCodeExporter commented 9 years ago 
You are right, iwyu only focuses on c and c++ (it has enough trouble with those 
two!)  If you wanted to you'd be welcome to try to work up a patch!

A lot of the infrastructure needed for the analysis has not yet been written 
for objective-c.  It may be more fruitful to start there.  For instance, 
RecursiveASTVisitor.h (in clang) has FIXMEs for quite a few objective-C 
constructs, I think.

I'll keep this open as a feature request, but I don't know objective-c at all, 
nor do I have the time to work on it if I did, so this will only get done if 
someone else wants to do it...

Original comment by csilv...@gmail.com on 6 Jul 2011 at 5:45

GoogleCodeExporter commented 9 years ago 
I've started working on Objective-C support and want to clarify how is better 
to prepare my changes. Currently I am working in Mercurial repository available 
at https://bitbucket.org/vsapsai/iwyu_objc/ So the questions are:

* Branch. Is it worth to create a branch for ObjC support? I've created branch 
to simplify sync between Mercurial and SVN repos, but changes for ObjC don't 
break the rest of code, so I guess they can be put into the trunk.

* Size of patches. I think patch (or a few patches for review) should represent 
a separate ObjC construction. For example, patch size is rougly equal to 3-4 
changesets  in mentioned repository. Are there any recommendations about patch 
size?

* Is it OK to ask all questions related to ObjC support implementation here? 
List of comments for this issues will grow big in this case.

Original comment by vsap...@gmail.com on 8 Aug 2011 at 10:23

GoogleCodeExporter commented 9 years ago 
Great! -- I'm glad to see you're working on this.

I don't know objective-C, as I mentioned, so I don't know how invasive a change 
this would be.  I expect iwyu is going to be rewritten pretty substantially in 
the next 6 months to a year -- we're seeing a need to separate out the policy 
decisions more cleanly, which may require a restart for this code.  I would 
rather not have to worry about objective-C as we made these changes, which will 
be complex enough as it is.

For these reasons, I think working in a branch may be best.  I don't know how 
to do branches on google code (or if it's possible), but if you have a branch 
already working, that should work fine.

Feel free to forward some patches this way, and I'll take a look and see if I 
can figure out what makes sense for applying them to trunk or not.  I 
understand the desire to keep the branch as close to the mainline as possible.

} * Is it OK to ask all questions related to ObjC support implementation here?

I think better will be to ask on include-what-you-use@googlegroups.com.

Original comment by csilv...@gmail.com on 9 Aug 2011 at 12:54