Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Support for Objective-C #47

Open
vsapsai opened this issue Jun 15, 2015 · 5 comments
Open

Support for Objective-C #47

vsapsai opened this issue Jun 15, 2015 · 5 comments
Labels
Priority-Low Type-Enhancement

Comments

@vsapsai
Copy link
Contributor

vsapsai commented Jun 15, 2015

Originally reported on Google Code with ID 47

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.

Reported by boredzo on 2011-07-03 05:59:52
@vsapsai
Copy link
Contributor Author

vsapsai commented Jun 15, 2015 

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

Reported by csilvers on 2011-07-06 17:45:45

  • Labels added: Type-Enhancement, Priority-Low
  • Labels removed: Type-Defect, Priority-Medium

@vsapsai
Copy link
Contributor Author

vsapsai commented Jun 15, 2015 

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.

Reported by vsapsai on 2011-08-08 22:23:11

@vsapsai
Copy link
Contributor Author

vsapsai commented Jun 15, 2015 

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.

Reported by csilvers on 2011-08-09 00:54:53

@EugeneZelenko EugeneZelenko mentioned this issue Aug 8, 2016
Closed
@storoj storoj mentioned this issue Nov 22, 2020
Open
@whihail
Copy link

whihail commented Jan 25, 2021

@vsapsai Hello, " https://bitbucket.org/vsapsai/iwyu_objc/ " this address is no longer accessible, because I am very interested in it, so I want to ask if I can migrate the code to github, thank you very much

@kimgr
Copy link
Contributor

kimgr commented Jan 25, 2021

@whihail See also #853

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Priority-Low Type-Enhancement
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@kimgr @vsapsai @whihail