r187735 - Implement C++'s restrictions on the type of an expression passed to a vararg

[Richard Smith]

On Mon, Aug 5, 2013 at 1:47 PM, John McCall <rjmccall at apple.com> wrote:

> On Aug 5, 2013, at 1:42 PM, Richard Smith <richard at metafoo.co.uk> wrote:
>
> On Mon, Aug 5, 2013 at 1:19 PM, John McCall <rjmccall at apple.com> wrote:
>
>> On Aug 5, 2013, at 11:49 AM, Richard Smith <richard-llvm at metafoo.co.uk>
>> wrote:
>>
>> Author: rsmith
>> Date: Mon Aug  5 13:49:43 2013
>> New Revision: 187735
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=187735&view=rev
>> Log:
>> Implement C++'s restrictions on the type of an expression passed to a
>> vararg
>> function: it can't be 'void' and it can't be an initializer list. We give
>> a
>> hard error for these rather than treating them as undefined behavior (we
>> can
>> and probably should do the same for non-POD types in C++11, but as of this
>> change we don't).
>>
>>
>> Doesn’t this change SFINAE behavior?
>>
>
> I'm not sure whether your "this" binds to the change or to the
> parenthetical in the comment.
>
> For the former, yes, and it's supposed to: 5.2.2/7 says the program is
> ill-formed.
>
> For the latter, this is "conditionally-supported with
> implementation-defined semantics". Per 1.4/2, this means "when the
> implementation does not support that construct, a conforming implementation
> shall issue at least one diagnostic message", and the intent is that
> implementations treat such constructs as being ill-formed if they do not
> support them. Our current implementation is conforming, if unfriendly.
> FWIW, g++ rejects such constructs.
>
>
> Are you sure it doesn’t just reject them if potentially evaluated?
>  Overloads where one option is (...) are pretty much standard.
>

Yes, indeed it does. Somewhat amusingly, it has the same behavior for
passing {} through an ellipsis, but gives an error for passing 'void'
through an ellipsis even in an unevaluated context.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130805/3fdcd117/attachment.html>