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

[John McCall]

On Aug 5, 2013, at 1:58 PM, Richard Smith <richard at metafoo.co.uk> wrote:
> 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.

Heh.  I agreeing that unconditionally erroring on passing void and {} through ... is the right thing to do.

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130805/eea93a1e/attachment.html>