[patch] Make "C++98 requires an accessible copy constructor" warning DefaultIgnore

[Nico Weber]

Ah, that makes sense. Here's another version that
moves CXX98CompatBindToTemporaryCopy over and
makes ext_rvalue_to_reference_temp_copy_no_viable an Extension. (For some
reason, I had read your second mail as "ou should also move the existing
-Wc++98-compat warnings over" and thought you meant all of them.)

On Sat, Sep 6, 2014 at 8:14 PM, Richard Smith <richard at metafoo.co.uk> wrote:

> On Sat, Sep 6, 2014 at 5:31 PM, Nico Weber <thakis at chromium.org> wrote:
>
>> On Sat, Sep 6, 2014 at 5:02 PM, Nico Weber <thakis at chromium.org> wrote:
>>
>>> On Sat, Sep 6, 2014 at 4:38 PM, Richard Smith <richard at metafoo.co.uk>
>>> wrote:
>>>
>>>> -Wc++98-compat doesn't make sense here: that warning group is for
>>>> warning on code that is valid in the current language but not in C++98.
>>>>
>>>
>>> The same is true for warn_cxx98_compat_enumerator_list_comma (which is
>>> in CXX98CompatPedantic) too though, right?
>>>
>>
> That's not how the cxx98_compat warnings work. This is what we do there:
>
>       if (!getLangOpts().C99 && !getLangOpts().CPlusPlus11)
>         Diag(CommaLoc, getLangOpts().CPlusPlus ?
>                diag::ext_enumerator_list_comma_cxx :
>                diag::ext_enumerator_list_comma_c)
>           << FixItHint::CreateRemoval(CommaLoc);
>       else if (getLangOpts().CPlusPlus11)
>         Diag(CommaLoc, diag::warn_cxx98_compat_enumerator_list_comma)
>           << FixItHint::CreateRemoval(CommaLoc);
>
> Note that we never produce a -Wc++98-compat warning in C++98 mode. And we
> do a similar thing for this warning, but it's a little more complex because
> we can't go through the motions of creating the temporary in C++11 mode,
> since that might trigger template instantiations we're not allowed to
> perform etc.
>
> …anyhoo, here's a version that just makes this warning an Extension.
>>
>
> You should move over ext_rvalue_to_reference_temp_copy_no_viable too. It
> doesn't make sense to downgrade only one of these two to an extension
> (either we ignore the temporary copy as an extension or we don't; we
> shouldn't be halfway between).
>
>
>> I didn't move CXX98CompatBindToTemporaryCopy to
>> CXX98CompatPedanticbecause that seems like an unrelated change,
>>
>
> It isn't: -Wc++98-compat-pedantic is supposed to warn on things that would
> warned about in -pedantic C++98 mode. Since you're moving this warning from
> ExtWarn to Extension, that means the corresponding -Wc++98-compat warning
> should move to -Wc++98-compat-pedantic.
>
> and because it contradicts the comment above CXX98CompatPedantic:
>>
>> // Warnings for C++11 features which are Extensions in C++98 mode.
>>
>
> You're making the C++11 "ignore the temporary copy when binding a
> reference to a temporary of the same type" feature an Extension in C++98
> mode, so -Wc++98-compat-bind-to-temporary-copy belongs in the
> -Wc++98-compat-pedantic group in C++11 mode. I don't see a contradiction
> with the comment, but maybe we could clarify it somehow?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140914/9cdee5c7/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: clang-bind-to-temp.patch
Type: application/octet-stream
Size: 5297 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140914/9cdee5c7/attachment.obj>