<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Dec 3, 2013, at 2:05 PM, Richard Smith <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">On Tue, Dec 3, 2013 at 1:46 PM, jahanian <span dir="ltr"><<a href="mailto:fjahanian@apple.com" target="_blank">fjahanian@apple.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
On Dec 3, 2013, at 1:19 PM, Arthur O'Dwyer <<a href="mailto:arthur.j.odwyer@gmail.com">arthur.j.odwyer@gmail.com</a>> wrote:<br>
<br>
> Richard Smith originally wrote:<br>
>> This is a frontend bug, not an IRGen bug; the test case is ill-formed. "return;"<br>
>> can be used in a constructor or destructor, but "return <expression-with-type-void>;"<br>
>> cannot.<br>
><br>
> Fariborz Jahanian wrote in response to my comments:<br>
>> There is a big difference here. returning a non-void expression in C::C() is allowed<br>
>> under an extension warning flag (ext_return_has_expr is ExtWarn<…>) while returning<br>
>> a void expression in C::C() is always an error.<br>
><br>
> Returning a non-void expression in C::C() is NOT allowed, not in any<br>
> dialect of C++, as far as I can tell.<br>
> The codepath under ext_return_has_expr is actually dealing with a GNU<br>
> C (not C++) extension that allows "return void_expr();" (not<br>
> "non_void_expr") in a function returning void. Here's how to trigger<br>
> that diagnostic:<br>
><br>
> $ clang test.c -Wpedantic -c<br>
> test.c:1:26: warning: void function 'bar' should not return void<br>
> expression [-Wpedantic]<br>
> void foo(); void bar() { return foo(); }<br>
> ^ ~~~~~<br>
><br>
> My point stands, as far as I can tell. And the reason you've had so<br>
> much trouble understanding this code is that it's really convoluted<br>
> and confusing! We should be trying to *simplify* it, not complicate it<br>
> by adding EVEN MORE codepaths and inconsistent behavior.<br>
<br>
</div></div>Code was simple enough to understand. I based my change on Richard’s comment<br>
that this should not be allowed (-Wpedantic or not).<br>
<br>
void foo(); C::C() { return foo(); }<br>
<br>
This cannot be consolidated with a diagnostic which allows -Wpedantic warning.<br>
So, another code path added to check for this condition. Feel free to change it provided<br>
unconditional error remains for above test case.</blockquote><div><br></div><div>What happens if you build this:</div><div><br></div><div>int foo(); C::C() { return foo(); } </div><div><br></div><div>... for ARM, with -Wno-return-type? Does that crash too?</div></div></div></div></blockquote>No. this works. Problem was trying to returning a ‘void’ expression in IR.</div><div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div><br></div><div>I was not aware that we had an extension allowing returning a (non-void) value from a function with a 'void' return type, but it appears we do. Does anyone know the history here?</div><div><br>
</div><div>Since we do have this extension (and assuming we don't intend to remove it), I agree that the return-void-expression and return-non-void-expression cases should behave the same. Within a ctor or dtor, either neither should be allowed as an extension or both should.</div>
<div><br></div><div>I think we need two changes here: 1) an IRGen fix, similar to Fariborz's original patch, but checking whether we're in a ctor/dtor rather than checking if the returned expression has type 'void', and 2) a tweak to this change, to treat the above case as an extension (to match our existing behavior).</div>
</div></div></div>
</blockquote><br></div><div>sgtm. Consolidation of the warning/errors is now trivial. I will take a look when I get the chance.</div><div><br></div><div>- Thanks, Fariborz</div><div><br></div><br></body></html>