Why won't Xcode recognize a typedef from a header that's being properly imported?

Question

I used to have a class called Constants. In it was this typedef:

typedef enum visible_thing {

    BACKGROUND,
    BACKGROUND_COLOR,
    MAIN_WINDOW

} VISIBLE_THING;

And my, was life rosy! I was importing 'Constants.h` wherever I needed to access this type, and it all worked.

Then I decided to nuke the Constants class. I took the typedef and I put it in another class, for clarity let's call it OtherClass. I went through and changed all the imports of Constants.h to imports of OtherClass.h That's all I did, I didn't touch any other code. And now the whole thing's broke!

Methods that worked perfectly with Constants now give me this error: Parse Issue - Expected a type. What the heck? I sure hope someone has some leads on this!

Update: frustratingly, this is one of those problems that just seemed to go away on its own without explanation. I answered my own question, below, with a workaround I'd found that entailed #import-ing the same header multiple times in one file. But today I removed the extra #import, and everything still worked. Arg. Computers!

Answer 1

I got the same "Expected a type", and it turns out that it was caused by an imports loop. I reproduced it with the following simple example:

A.h:

#import "B.h"

typedef enum {
    SomeEnumA
} SomeEnum;

@interface A : NSObject

@end

B.h:

#import "A.h"

@interface B : NSObject

- (void) func:(SomeEnum)arg;

@end

The compiler complains about SomeEnum unknown in B.h - while compiling A.m (which just imports A.h). This happens because A.h imports B.h which imports A.h. The imports loop doesn't occur, so B.h in this case does not include the A.h code where the type is defined.

The issue can be easily solved by moving the definition of the enum to a separate SomeEnum.h .

Answer 2

I would probably try to figure out what's going on, because what ever is causing this to happen might cause other mysterious bugs in the future, and by that point you might have forgotten about this, which could make it more difficult to track down the cause of the future bugs.

I would try to isolate the problem. A few things that you could try:

• progressively commenting out code in the InnerClass interface to see if you can get the problem to go away.
• manually adding a typedef at the top of your file with a different type name (and editing the rest of your code appropriately) to see if the problem is still there.
• posting your .h file and OtherClass.h file to see if anyone else can spot the problem
• David H's suggestion of creating a demo project to see if you can reproduce the problem

I think it depends on what your project is, if it's just something small and fast that you want to get working, it probably doesn't matter, but if it's going to be a larger project and you forsee your code base expanding, or if it's something that other coders are going to be working on as well, I would try to understand what's happening here.