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

[Richard Smith]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130805/6ccfacf0/attachment.html>