r183883 - Implement core issue 903: only integer literals with value 0 and prvalues of

[Richard Smith]

On Mon, Jun 17, 2013 at 2:37 PM, Sebastian Redl
<sebastian.redl at getdesigned.at> wrote:
>
> On 17.06.2013, at 21:42, Richard Smith wrote:
>
>> On Mon, Jun 17, 2013 at 12:23 PM, Jordan Rose <jordan_rose at apple.com> wrote:
>>>
>>> On Jun 17, 2013, at 12:20 , Nico Weber <thakis at chromium.org> wrote:
>>>
>>> On Mon, Jun 17, 2013 at 9:38 AM, Jordan Rose <jordan_rose at apple.com> wrote:
>>>>
>>>> *sigh* I can't say this is the wrong thing to do—in fact, it's the kind of
>>>> restriction I usually like—but for the record this breaks OS X's (ancient)
>>>> libstdc++ implementation of <tr1/unordered_map> when compiling under
>>>> -std=c++11. I don't think that's such an important configuration, though.
>>>
>>>
>>> That means it breaks all programs that try to build in C++11 mode but still
>>> need to ship to 10.6 (like, say, Chromium). Can this be worked around
>>> somehow?
>>>
>>>
>>> Will that still be true by the next Xcode release? It's not in 4.6.2, and I
>>> can watch to make sure it stays out of Xcode 5. Do you really need to build
>>> your 10.6-compatible binary with trunk Clang in C++11 mode?
>>>
>>> Richard, I suppose you could make it a warning...
>>
>> That's actually pretty tricky, due to its effects on SFINAE, overload
>> resolution, and so on. But we should be able to add a more limited
>> workaround which suffices for this specific libstdc++ issue.
>
> We had workarounds of the type "make this an error in SFINAE context and a warning otherwise" before.

This is a much harder case, though, because of the effect on overload
resolution (and more generally because the point where an error is
detected can be distant from the point where we make the decision). If
we only want to work around this one libstdc++ bug, we can just detect
the case where a return statement's expression is the 'false' literal.