r196296 - Issue diagnostic when constructor or destructor

[jahanian]

On Dec 3, 2013, at 1:19 PM, Arthur O'Dwyer <arthur.j.odwyer at gmail.com> wrote:

> Richard Smith originally wrote:
>> This is a frontend bug, not an IRGen bug; the test case is ill-formed. "return;"
>> can be used in a constructor or destructor, but "return <expression-with-type-void>;"
>> cannot.
> 
> Fariborz Jahanian wrote in response to my comments:
>> There is a big difference here. returning a non-void expression in C::C() is allowed
>> under an extension warning flag (ext_return_has_expr is ExtWarn<…>) while returning
>> a void expression in C::C() is always an error.
> 
> Returning a non-void expression in C::C() is NOT allowed, not in any
> dialect of C++, as far as I can tell.
> The codepath under ext_return_has_expr is actually dealing with a GNU
> C (not C++) extension that allows "return void_expr();" (not
> "non_void_expr") in a function returning void. Here's how to trigger
> that diagnostic:
> 
>    $ clang test.c -Wpedantic -c
>    test.c:1:26: warning: void function 'bar' should not return void
> expression [-Wpedantic]
>    void foo(); void bar() { return foo(); }
>                             ^      ~~~~~
> 
> My point stands, as far as I can tell. And the reason you've had so
> much trouble understanding this code is that it's really convoluted
> and confusing! We should be trying to *simplify* it, not complicate it
> by adding EVEN MORE codepaths and inconsistent behavior.

Code was simple enough to understand. I based my change on Richard’s comment
that this should not be allowed (-Wpedantic or not).

void foo(); C::C() { return foo(); }

This cannot be consolidated with a diagnostic which allows -Wpedantic warning.
So, another code path added to check for this condition. Feel free to change it provided
unconditional error remains for above test case.

- Fariborz


> 
> –Arthur