I just had a bizarre failure in a new unit test, which I finally tracked down
to a callback block returning NO when it should have returned YES. In fact I’d
forgotten to add “return YES” at the end of the block, which the compiler
should have flagged as an error — instead it somehow synthesized a NO return.
I reduced it down to the following invalid code, which compiles without
warnings or errors:
BOOL (^block)();
block = ^BOOL {
@try {
} @catch (...) {
}
};
It looks like as soon as you add an @try statement to a block, the compiler
stops enforcing that the block has to return a value. Yikes! In my original
code, the @try was hidden inside the definition of the XCTAssert() macro, so an
equivalent test case is
BOOL (^block)();
block = ^BOOL {
XCTAssert(2 + 2 == 4);
};
I’m 99% certain this is a Clang bug, but I thought I’d ask first in case any of
you rules lawyers can think of a reason this should be valid :)
—Jens
PS: I’ve got Xcode 7.3, i.e. Apple LLVM version 7.3.0 (clang-703.0.29) Target:
x86_64-apple-darwin15.5.0 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Objc-language mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/objc-language/archive%40mail-archive.com
This email sent to [email protected]
