The new version of LLVM in Xcode 4.4 reports an error in Controller.m

[smono]

When compiling with Xcode 4.4 (i.e., Apple LLVM 4.0 which is not under NDA), an error is reported in Controller.m:

macosx/Controller.m:2101:13: Return type 'int' must match previous return type 'NSComparisonResult' (aka 'long') when block literal has unspecified explicit return type

The issue can be resolved with a cast, see attached diff.

[livings124]

NSOrderedSame is in the NSComparisonResult enum. Why would the cast be necessary?

[smono]

Explicit return type instead of a cast

[smono]

That is a good question that you'll have to ask the compiler about.

Without the cast, it throws an error (not a warning) and hence does not complete the build. With the cast it builds.

From the error message one gleans that NSComparisonResult is a long and NSOrderedSame is an int (no idea why) and that discrepancy apparently triggers a compiler check for inconsistent return values in blocks with unspecified return types.

[smono]

This is of course a trivial issue, but I took the opportunity to dig a little deeper into block declarations.

First, it all begins because the compiler somehow does think that NSOrderedSame has the same type as NSComparisonResult, which I would have expected.

However, once that difference is established, a block with an undeclared return type will have its return type inferred by the compiler (unlike functions).

Since there are two return statements with different types, this is an ambiguity that the new compiler (Apple LLVM 4.0) flags as an error.

So if a cast on the return is a bit ugly, another solution could be to make the return type from the block explicit, as in the attached diff (explicitreturntype.diff). The cast will of course still happen, but in this case it can be handled silently by the compiler in an unambiguous manner.

Again, apart from getting the code to compile, to me this was just a useful opportunity to get a bit deeper into blocks.

[livings124]

Thanks for looking this over! r13354.