[PATCH] D18123: Fix implicit copy ctor and copy assignment operator warnings when -Wdeprecated passed.

[don hinton via cfe-commits]

On Mon, Mar 14, 2016 at 6:24 PM, David Blaikie <dblaikie at gmail.com> wrote:

>
>
> On Mon, Mar 14, 2016 at 3:07 PM, don hinton <hintonda at gmail.com> wrote:
>
>> UnresolvedSetImpl isn't even constructible, much less copy constructible,
>> but it is a public base class to UnresolvedSet, it it is -- at least until
>> we turn it off by deleting the copy ctor.
>>
>> template <unsigned InlineCapacity> class UnresolvedSet :
>>     public UnresolvedSetImpl {
>>   SmallVector<DeclAccessPair, InlineCapacity> Decls;
>> };
>>
>> But I'm not sure why we would need to since all it does is contain a
>> SmallVector, and it supports all that behavior.  The problem here is that
>> making UnresolvedSetImpl's ctor private and defining it, means you have to
>> do something with the other ones as well.  I'm happy to turn the all off,
>> but didn't see a good reason to do so.
>>
>
> Fair - I'm not too fussed, there, to be sure. If we're going to do it,
> perhaps we should = default in the move ops too? (except those aren't
> implicitly defaultible in MSVC... blah)
>

Yes, I included the move ops, move ctor and move assignment.


>
> Maybe best to just wait until there's a need for them? I'm not sure.
> *shrug*
>

Sure, that's fine.  However, I think we should delete them in LookupResult,
right?  The implicit copy and assignment ops are wrong and leak otherwise.


>
>
>> As for libcxx and libcxxabi, they are 2 separate repos (at least in git).
>>
>
> Yep, wasn't expecting the fixes to go in the same code review or anything
> - just wondering about direction.
>
>
>>   Fixing libcxx is easy since it already defines a macro for
>> throw()/noexcept.  Unfortunately, libcxxapi doesn't, though it's easy
>> enough to define.
>>
>
> *nod*
>
>
>>
>> On Mon, Mar 14, 2016 at 5:33 PM, David Blaikie <dblaikie at gmail.com>
>> wrote:
>>
>>> UNresolvedSetImpl isn't copy constructible, so should it really be copy
>>> assignable? (it looks like it only needs to be so because of LookupResult -
>>> so once LookupResult is fixed, UnresolvedSetImpl can go back to the way it
>>> was)
>>>
>>> Perhaps we should just wait for the fix for LookupResult copying in
>>> SemaStmtAsm from Marina?
>>>
>>> Are you planning to cleanup -Wdeprecated in libcxx and libcxxabi too?
>>>
>>> I did most of the -Wdeprecated cleanup late last year - but when I tried
>>> to turn it on I hit issues in various stdlibs, etc. It'd be great to finish
>>> the cleanup, or suppress it in system headers, etc, and get it turned on.
>>>
>>> On Mon, Mar 14, 2016 at 12:29 PM, don hinton via cfe-commits <
>>> cfe-commits at lists.llvm.org> wrote:
>>>
>>>> hintonda added a comment.
>>>>
>>>> Btw, what do you think about making -Wdeprecated the default for
>>>> llvm/clang builds?
>>>>
>>>> With this change, llvm/clang will be clean.  However, libcxx and
>>>> libcxxabi have a bunch of throw warnings.
>>>>
>>>>
>>>> http://reviews.llvm.org/D18123
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> cfe-commits mailing list
>>>> cfe-commits at lists.llvm.org
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20160314/1c63ca28/attachment.html>