> On May 6, 2016, at 11:28 AM, Jens Alfke <[email protected]> wrote:
>
> 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.
It is probably just falling off the end and leaving the result uninitialized.
> 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 :)
It's likely that the compiler is just being more conservative about control
flow in the presence of try/catch, but I think we could reasonably catch cases
like this; please file a bug.
John.
_______________________________________________
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]
